Congratulations to Qualcomm

One of the rewards of working in the evaluation and testing business is to see our customers succeed and show the results of their efforts. We are always happy to work with organizations who are committed to IT security and want to improve their products and processes for the benefit of their customers.

In that spirit we would like to congratulate Qualcomm for their recent successes in attaining FIPS 140-2 certificates for several of their cryptographic modules. We are honored to be a partner in Qualcomm's FIPS 140-2 endeavors.

Read Qualcomm's blog article here.

Rise & Fall of MD5

by Richard Fant

The Rise
MD5 (message digest version 5) was developed in 1991 and is still very popular today, with a wide range of commercial and government applications. MD5 is used to generate hash values of passwords stored on a system as opposed to storing the passwords in plain text. This password protection method was used by many popular commercial websites such as LinkedIn, eHarmony, and LastFM. In addition, many government agencies originally adopted MD5 for official use.

How it Works
If you take a large set of numbers and apply mathematical operations on it to reduce the large set to a much smaller value, those operations are collectively called a hashing function. Particularly, in Computer Sciences, a hash function is any function that can be used to map data of arbitrary size to fixed-size values. The values returned by a hash function are called hash values, hash codes, digests, or simply hashes.

A typical use of hashing functions is to verify the integrity of files after a file transfer. For example, a person wishing to transfer a document called File A over the internet would first hash the contents of File A into a value representing File A. At the destination, the newly arrived file, call it File A’, is similarly hashed into a value representing File A’. The two hash values are compared. If both values are the same, then File A’ is the same as File A which means the transfer was successful and no damage occurred.

As with all hashing functions, MD5 is designed to be a one-way function: it should be extremely difficult to reverse engineer the output to determine the input. One of the most common ways to attack a one-way function, is to run a brute-force search for all possible inputs to see if they generate something which matches the same specific output. This is known as finding a hash collision. The security strenght of a hash function is measured by how difficult it is to find a hash collision.

How is it Used
MD5 is frequently used as hashing function for passwords. For example, a user’s LinkedIn password such as “MyPasswordIsGood!” could be put into a hash function which would generate a 128-bit hash value starting with something like “7A07C” (the actual hash value would be longer, but shortened here for convenience). This hashed password could be stored on the LinkedIn website. Whenever the user logged into the website with their plain text password, it would be hashed and then compared with what was already stored there. If they matched, the user was authorized access. This process of hashing the password means that simply stealing hashed passwords from the website is insufficient to gain access. This also means that the user’s plain text password is never stored on the website itself which increases overall security. However, there is a weakness in the process, the previously mentioned hash collision.

A hash collision is when two different input values generate the same output value. In the above example, suppose that “MyPasswordIsGood!” generated “7A07C” as output. A hash collision is when another input such as “TqBfjO7#DB” actually hashes to the same value “7A07C”. This means an attacker would not have to know the original plain text password to gain access to a website. Instead, using brute force an attacker could run billions or trillions of random input values into the MD5 hash function until they saw the expected output “7A07C”. And thus, the attacker could access the website using the second input value “TqBfjO7#DB”.

With only 128 bits for the size of its hash value, the probability of having two MD5 hash values accidentally colliding is approximately 1.47*10-29. Given today’s computing power, an MD5 collision can be generated in a matter of seconds. This was the downfall of MD5.

The Fall
MD5 runs fairly quickly and has a simple algorithm which makes it easy to implement. The main weakness with MD5 is that it is relatively easy to generate hash collisions using today’s computer technologies.

In 2005, security researchers announced that MD5 should no longer be considered secure due to an experiment that showed by running a collision-generating brute-force algorithm on a standard PC notebook for 8 hours, a hash collision occurred in MD5. However, MD5 was so deeply embedded in applications and websites, many considered it too expensive to discontinue its use since that would necessitate rewriting code for thousands of applications.

That attitude began to change when several major corporations began reporting security breaches in their systems where MD5 was used. For example in June 2012, LinkedIn announced that 6.4 million hashed passwords had been leaked to a Russian website and that many of those MD5-hashed passwords had been reverse-engineered using brute force to find its matching input strings. In the same month, Microsoft reported that a new piece of malware, called Flame, was taking advantage of the hash collision security flaw in MD5 to generate a counterfeit digital certificate. This forged certificate convinced Windows Operating Systems, that the Flame malware was a legitimate Microsoft product and should be allowed through the firewall. This allowed the malware to bypass many anti-virus programs and install itself on Windows-based PC’s.

As recently as 2019, nearly 15 years after the publication of the flaws of MD5, one quarter of content management systems used in websites still use MD5 for password hashing.

Wrapping Up
Using Moore’s Law, the predicted computational power of a personal computer will double approximately every two years. This means the computer used in the brute-force attack of MD5 in 2005 was 2⁷ times as powerful as one built in 1991 when MD5 was released. A computer in 2020 is 2¹⁴ times as powerful as a 1991 model. This means when MD5 was released in 1991, the exponential increase of computing power was not taken into account by its users which lead to an overabundance of confidence in the security of MD5.

Final Thoughts
Using MD5 to verify a file hasn’t been corrupted or damaged is a reasonable use of this hash function. Using MD5 to generate the hash value of passwords is a security breach waiting to happen.

atsec China adds two PCI SSF Assessor Qualifications

atsec China has been qualified by the PCI SSC (Payment Card Industry Security Standards Council) as a Secure Software Lifecycle (SLC) Assessor and Secure Software Assessor company under the PCI Software Security Framework (SSF) program to evaluate a vendor's software lifecycle and/or validate a vendor's payment software.

The PCI SSF is a collection of standards and programs for the secure design and development of payment software. Security of payment software is a crucial part of the payment transaction flow and is essential to facilitate reliable and accurate payment transactions. The SSF replaces the Payment Application Data Security Standard (PA-DSS) with modern requirements that support a broader array of payment software types, technologies, and development methodologies. With its outcome-focused requirements, the SSF provides more agility for developers to incorporate payment application security with nimble development practices and frequent update cycles. The SSF enables accelerated provision of customization and features for payment applications for merchants without compromising security. It also improves consistency and transparency in testing payment applications, which elevates validation assurance for merchants, service providers, and acquirers that implement and manage the use of payment solutions.

As a qualified Secure Software Lifecycle (SLC) Assessor, atsec can perform Secure SLC Assessments according to the Secure Software Lifecyle (Secure SLC) Standard. The Secure SLC Standard is intended for validating the lifecycle practices for software vendors that develop software for the payments industry. This standard provides security requirements for payment software vendors to integrate security throughout the entire software lifecycle, which results in software that is secure by design and able to withstand attacks. Upon successful validation by atsec as one of the Secure SLC Assessors, software vendors will be recognized on the PCI SSC List of Secure SLC Qualified Vendors. Secure SLC Qualified Vendors are empowered to perform and self-attest to their own software “delta” assessments with reduced assessor involvement or oversight.

As a qualified Secure Software Assessor, atsec can perform Secure Software Assessments according to the Secure Software Standard. This standard provides security requirements for building secure payment software to protect the integrity and the confidentiality of sensitive data that is stored, processed, or transmitted in association with payment transactions. Upon successful evaluation by atsec as one of the Secure Software Assessors, validated payment software will be recognized on the PCI SSC List of Validated Payment Software, which will supersede the current List of Validated Payment Applications when PA-DSS is retired the end of October 2022.

The SSF Assessors list can be found on the official website of PCI SSC:
https://www.pcisecuritystandards.org/assessors_and_solutions/software_security_framework_assessors

In addition to SSF assessor, as an accredited PCI QSA, ASV, QPA, PA QSA, P2PE, 3DS assessor and PFI, atsec China offers a full range of services to support organizations in achieving PCI compliance.

For more information about atsec’s PCI services, please visit:
http://www.atsec.cn/it-security-services/pci/en/index.html

Data Recycling to Become Mandatory in 2022

According to sources in the DPA (Data Protection Agency) new guidelines will be issued soon that will make digital trash separation mandatory. Every year an estimated 240 zettabytes of re-usable bits are thrown into desktop trash cans.

The new guidelines require operating system manufacturers to implement a recycling bin next to the trash can on the desktop. On Linux systems the addition of /dev/green to the existing /dev/null is being discussed.

The collected data will be re-used in the production of cat videos and make-up tutorials and is hailed as an important step forward.

Ryan Hill, Quality Manager at atsec commented: “It always bugged me to just throw away obsolete meeting minutes and draft versions of reports. Now I have the chance to make a difference by being a responsible digital citizen.”

Security experts warn that data leakage could become an issue. ‘You have to be careful when you recycle bits and bytes. You don’t want to see an unboxing video – but it’s your quarterly report being unboxed.”

Further steps to reduce digital trash are currently field-tested, including an initiative to sort zeros and ones and store them separately for more efficiency.


In addition to recycling, some digital environmental groups are recommending data composting as well. Wilbur Sycamore, President of Save our Bits, said, “Recycling is great, but the DPA should also require a data compost bin. That way all that food data waste, such as pictures of meals and recipe blogs, can be made into data compost that will allow us to grow bigger and more robust data!” Scientists estimate that a single month of Instagram food photos could be used to create 50,000 Tik Tok videos.

As with any new initiative there are also skeptics. King Ables, Security Consultant at atsec information security corporation, said, “Unfortunately, these guidelines are unlikely to produce the desired results. Sure, you can reuse the raw data, but when the ones and zeros have been separated, all you can build are null strings and broadcast addresses. What's the point of that?"

Meltdown Attack: 2 Years Later

by Richard Fant  

Meltdown Attack:  2 years later
In February 2017, independent security researchers discovered a catastrophic security flaw in the cache design for processors developed by Intel Corporation. After embargoing the information for almost a year while working on a fix, Intel publicly announced in January 2018 the security flaw known as the Meltdown Attack.

At a high level, the Meltdown Attack allows a user application to read data stored inside kernel level memory. In other words, it “melted down” the security boundary between the user and the kernel.

How can a user program read data stored in restricted memory?
To reduce execution time, most modern processors implement a strategy called speculative execution (a.k.a. Out of Order Execution). While the details are proprietary, the basic idea is that by looking at the history of the most recently executed CPU instructions, the processor can “speculate” what the user’s code will do in the future. In the anticipation that its prediction will be true, the processor will pre-fetch data from memory and have it ready in cache and registers for those future instructions.

If the processor correctly predicts what data an instruction will need, the data can be fetched from the cache instead of main memory. And since cache access is orders of magnitude faster than memory accesses, the overall execution time is greatly reduced. On the other hand, if a processor’s predictions about future instructions turns out to be false, the processor will simply clean up any registers and memory used in the speculation and continue execution.

This is the source of the vulnerability: the designers neglected to also clean up the “dirty” cache left behind after a failed speculation.

To illustrate this, consider the pseudo code below:

for i=1 to 100
    if (i==99) then
        break;
    else
        array [i] += array [i] * 2;

In this snippet, the processor notices that for the first 98 iterations, the “else” branch has been taken. It would be reasonable for the processor to predict that for the 99th iteration, the “else” branch will be taken once again. Because of this, the processor will pre-fetch the data at array [99] from memory and store it in cache. However, in this example, the 99th iteration in fact causes the for-loop to break out. However, the data stored in array [99] has already been stored in cache. Since the processor didn’t flush the cache after its failed speculation, the cache is now “dirty” with data that should have been removed.

How is this flaw exploited?
A sophisticated attacker could set up a program where a user level request to kernel memory could be speculatively executed by the processor. Even though the kernel would eventually reject such a request, it has been publicly demonstrated that the user program can still read the “dirty” cache even after the speculation failed and the kernel rejected the access request. This is the basis for an ongoing race-condition between the speculative execution and the rejection of the request: if the request is rejected first, then there will be no speculation. If the speculation happens first, then the cache will already be dirty by the time the rejection happens. There are several published algorithms that can speed up the speculation and delay the rejection. This leads to dirty caches happening more often.

This means a malicious programmer could read all of kernel memory by methodically exploiting this flaw, byte by byte, using a dirty cache. This attack is especially devastating because the victim wouldn’t even know the Meltdown Attack had occurred.

Who does this effect?
Speculative Execution was introduced on Intel processors in 1995. In December 2017, Intel and OEMs began releasing firmware & software fixes. The actual design flaw itself wasn’t addressed in hardware until October 2018. This means that potentially any Intel processor manufactured between 1995 and 2018 is at risk. In addition, any Intel CPU implemented in a virtual machine could also have this vulnerability.

Where are we now, 2 years later?
As of today, there have been no published reports of any successful Meltdown Attacks in the real world. This doesn’t mean these attacks haven’t happened, just that they weren’t reported (or possibly not even discovered by their victims). There have also been several variants of the Meltdown Attack discovered in the last two years which use the same flaw of a dirty cache with speculative execution.

Intel stated in October 2018 that their 9th-generation processor family would include additional protection against Meltdown. Of course, no details were provided since that could provide too much information for an attacker. Other companies like Apple and Microsoft have released applications that can determine if your processor is vulnerable to the Meltdown Attack.

Final Thoughts
Keep Calm and Carry On:  if you have an Intel processor built in 2018 or earlier, you’re probably at risk. Download any firmware or software updates that are recommended by your computer manufacturer. If your processor was built in 2019 or later, you should be safe from attacks of this kind.

International Women's Day

Happy International Women's Day to all our wonderful atsec colleagues in Europe, US and Asia.

Zen, or the Art of FIPS Certificate Maintenance

by Andreas Fabis

When we talk to our customers about FIPS 140-2 testing some questions regarding certificate maintenance frequently come up:

• “What happens to my certificate if I make changes to my module?”
• “Do I have to re-certify every single time I make a small change?”
• “What if we want to patch a vulnerability?”

There are many factors that can lead to module or platform changes: technical, business and marketing, to name a few. Navigating the rules and options of FIPS 140-2 re-certification can be challenging, and currently there are additional factors and deadlines to consider:

• The switch from FIPS 140-2 to FIPS 140-3 (mandatory after September 22nd 2021)
• The switch from the Cryptographic Algorithm Validation System (CAVS) to the Automated Cryptographic Validation Testing (ACVT) (mandatory after June 30th 2020)
• The switch from FIPS I40-2 IG 7.15 to SP 800-90B compliance (mandatory after November 8th 2020)

From a FIPS 140-2 point of view, the exact details of the re-certification process and the requirements for the different re-certification scenarios are explained in G.8 of the FIPS 140-2 Implementation Guidance (IG). This article is intended to help customers understand the practical implications of the different scenarios.

Non-security-relevant changes to the module or changes to the platform
Changes to hardware, software or firmware components that do not affect any security relevant items within the module are covered by scenario 1 (also known as a 1-SUB). Changing the module platform (for a software module) or adding a new platform to an existing module are also common scenarios for 1-SUBs. The laboratory will review the vendor’s documentation to make sure that no security relevant items are affected by either the change of module or the change of platform. In case of changing or adding a new platform, the module needs to be tested on the new platform. The lab then submits a package to the Cryptographic Module Validation Program (CMVP) that contains a letter explaining the nature of the change, the laboratory’s assessment and—depending on the changes—an updated Security Policy and/or draft certificate. Upon the approval of 1-SUB, the existing FIPS certificate will be updated to reflect the new version of the module or the new platform(s). The certificate expiration date remains the same.

Another option is to add the new platform as a vendor affirmed platform. These platforms will not be listed on the certificate itself, but in the Security Policy that is attached to the certificate listing. Vendor affirmation is not backed up by the CMVP and hence does not carry as much weight as laboratory testing and validation. It is up to the customer whether they accept a vendor’s claim that the module works as expected on the affirmed platforms.

Security relevant changes to the module
If there are security relevant changes to the module itself the submission scenario depends on the amount of changes. If the changes are relatively minor (less than 30%), scenario 3 (3-SUB) is applicable. This means that the laboratory will assess the amount and nature of the changes, then perform the applicable testing to make sure the affected security functions still work as expected. The laboratory will submit a test report to the CMVP and upon positive review a new certificate will be issued which is valid for 5 years.

Scenario 3A (3A-SUB) is specifically meant to address vulnerability patches if the vulnerability is on the official CVE list. In this case the CMVP waives the NIST fee as an incentive to vendors to patch vulnerabilities. The laboratory will perform the applicable regression testing and submit an updated test report. The CMVP will process the 3A-SUB at the speed of 1-SUB. In this case the existing certificate will be updated and the certificate expiration date remains the same.

If the amount of security-relevant change is above 30%, the module will be submitted under scenario 5 (5-SUB) which is equivalent to a new validation.

A quick summary of the most common re-certification scenarios:



What about FIPS 140-3?
Modules tested under FIPS 140-2, and their reports submitted before September 22nd 2021, once validated, will stay valid for 5 years. Once FIPS 140-3 has become mandatory, any re-validation of a module validated under FIPS 140-2 will automatically be a 5-SUB under FIPS 140-3.

Strategies
The best validation strategy depends on the business needs, development cycles and other variables and may include:

• Re-validation of major releases only
• Re-validation every 6 or 12 months (accumulate changes)
• Re-validation based on customer demand
• Re-validation to patch critical vulnerabilities

In the end the best course will be different for every organization. As a laboratory we can help you find the best solution for your particular needs.

My Experience During the COVID-19 Outbreak in China

by Yan Liu, Managing Director, atsec China

During the period of the novel coronavirus (COVID-19) outbreak in China, I, and many others, have cancelled parties with family, friends and colleagues—even during the traditional Chinese Lunar New Year. We have also decided to work remotely with atsec colleagues, customers, and partners. This gave me more time to think and learn, and I wanted to write something about my experience during this unique time.

I don’t believe that my education and knowledge can provide too much help for others regarding the current epidemic situation. The major contribution for changing the situation will be made by health organizations and centers for the control of disease.

Though there is a lot of information and many perspectives available through public media, I would like share my personal experience as well as the experience of the company just to keep a sort of public record of the event. This could also be regarded as a lesson-learned for our Business Continuity Plan, especially for other similar small professional service businesses like atsec.

1.     Safety and Health are the Only Priority
On January 26, 2020, the second day of Chinese Lunar New Year, we learned from the news of the breakout of COVID-19 in Wuhan, and that the situation was getting worse. After a conversation with a few colleagues, we informed the whole atsec China team that it would be better to work from home and reconvene after the Chinese New Year holiday, though we did not set a date when to come back to the office.

As of today, the whole atsec China team is still working from home.
We put the working-from-home plan into effect immediately, knowing that some of our colleagues still stay at their hometown in order to see their families during the Chinese new year, and it would not be safe to meet or take public transportation.

It was unknown at that moment, when life would go back to normal. At the same time we were putting our plan together, the government ordered a delay in returning to work after the New Year holiday and suggested that everyone stay home and avoid contact with others in order to better control the spread of the disease.

We are confident that the virus will be defeated, the problem is that nobody really knows how long it will take.

There were no traffic jams on the road, and no children playing in the park. Communication is mainly online.

On February 2, 2020, at 20:20 (note the sequence), a colleague suggested we take a group photo of the atsec China team in the cloud. As one colleague said, we looked serious but strong.

I then considered reporting the status of our safety to our other atsec colleagues outside China, as they might have been worried about us as well.

As I hesitated to start, we started to receive message and greetings from all our atsec colleagues around the world. The first message was from our CEO: “Please use all possible precautions. If you think you need to have all the people working from home and avoid using public transportation to come to work or customer meetings please do that.”

I assured him that our China team and families were safe at home. I also mentioned to my colleagues in other countries to please stay safe and take care, although the center of the virus outbreak was (at that time) far away from other countries.

As days go by, the team has had quite a few talks regarding the potential adjustment of scheduled
meetings.

2.     Home Office: Work remote, Work Smart!
Based on our experience and the nature of the business, working from home did not represent a major challenge. The team is used to working from home from time-to-time, though it meets regularly in the office for meetings or on-site testing.

Our policies and procedures for “working from home” needed just a slight update. All our security measures were already in place during normal operation including, but not limited to, account security management, VPN access to critical assets, encryption and decryption during communication, disk encryption, security of personal devices, and more.

No changes were required from all other colleagues from Shenzhen, Shanghai, and Guangzhou, who are already used to working remotely.

We did put off our regular face-to-face weekly and monthly meetings and moved to regular online meetings starting February 2, 2020.

During this time, we realized we miss each other.

Throughout the course of our online meetings, we shared our experiences on how to work from home more efficiently.

The following diagram, though it does not include details, represents the way we plan to work remotely.

A few members of the team would be open for video conferencing during online meetings, and even dress formally while video conferencing with customers.

An internal training server was established within atsec China in order to allow all employees to study the most recent information shared by other team members based on each person’s own schedule. We have also organized internal training and an exam for one of the recent security standards.

We used this situation as an opportunity to improve our internal methodology, tools, service level, and how we can provide assessment services to our customer efficiently (remote and/or on-site work). We have more time to improve our know-how and work on new qualifications.

From our colleagues’ reaction we all realize how confident the team is in working efficiently and securely from home, though at the same we are looking forward to being back in office soon.

3.     Industry impact
In the long term, we believe that this event will have very little impact on our industry and services. On the contrary, we think more attention will be given to security implementation, compliance, and assessment.

Public safety and security are different topics, though both use the same Chinese symbol “安全”. However, after this event, we think China and society overall will put more emphasis on topics such as: business continuity, incident (or emergency) response, compliance to regulation and standards, overall quality, and more.

In the short-term the outbreak might impact industries such as catering and tourism (hotels, airlines).
Cash flow might become an issue, especially for those small and mid-size companies which normally keep only a limited cash flow for running the business (e.g. less than three months). They might need loans in order to survive during this unique period. Things might be easier for companies which might have a better way to manage cash and have a long-term business plan. atsec China, has always managed to have a considerable cash flow and there will be not an issue.

Our business focuses only on independent security assessment and consulting services, and there will be no need for financial support from any organization. On the service side, most of our customers (e.g. payment service providers, merchants, banks, software vendors, etc.) have already started working with atsec remotely.

Although on-site work is necessary, most of our assessments and consulting services can also be provided remotely via interview, observation, and evidence examination. We have also improved our methods of working with customers via remote communications.

Normally from two to three days, up to a week, of on-site work is needed for a normal compliance assessment project. I expect a more efficient on-site communication practice could be considered after this period in order to save effort and cost for both the assessment team and assessed entities.

I have learned that most companies will probably consider reducing costs (e.g. their recruitment plan could be adjusted) in 2020. But so far few entities have considered reducing the budget for information security.

In addition, good habits of diligence and frugality are always a good thing.

4.    Face to face meetings vs Webinar
Face-to-face communication is always important in our business. atsec China planned to organize the 2020 China Payment Security Workshop in Chengdu on the 27th and 28th of March. Starting in November 2019, our team has set preparations for the event such as guest invitations, conference locations, hotel, transportation, presentations, and more.

In the middle of February, we cancelled the event and changed to an online event providing training free of charge. The first online training will be held on the 28th of February, 2020. We will provide an overview of the Payment Card Industry (PCI) security standards family, the Software Security Framework, and share our experience on PCI Data Security Standard (DSS) compliance. The next training will be on the 13th of March, 2020, with topics ranging from PCI 3DS, to PIN security and Point-to-Point Encryption (P2PE).

We have decided not to attend an industry meeting organized in Europe in the beginning of March. We are unsure whether a member of the atsec China team will be able to attend a conference later in April. I am looking forward to more face-to-face communication and meetings soon after this period.

Final Comments
We are expecting this uncomfortable situation to be resolved before summer so the atsec China team can celebrate the atsec 20th anniversary with the rest of our atsec colleagues in Europe.

Last and not least, I would like to express my appreciation for all of colleagues, family members, friends, customers, and partners who have given me support and courage during this difficult beginning of 2020. Last and most importantly, I want to take this opportunity to thank all the medical workers, who are currently helping patients, fighting the disease and protecting our health. To them I would like to express my heartfelt gratitude and highest respect.

Written by Yan Liu
Midnight, 24 February, 2020, in Beijing

New Service – eIDAS Trust Service Provider Assessments

atsec is happy to announce that we are now a licensed Conformity Assessment Body (CAB) under Electronic Identification, Authentication and Trust Services (eIDAS). eIDAS is an EU regulation on electronic identification and trust services for electronic transactions that applies as law within the whole of the EU.

Trust services include electronic signatures, electronic seals, time stamps, electronic delivery services and website authentication. Together with eID, these elements are essential for the establishment of legal certainty, trust and security in electronic transactions.

The eIDAS regulation also sets out what trust service providers need to do in order to gain qualified status, which entitles them to be listed on a trusted list and to use an EU trust mark.

In order to become a qualified trust service provide, the vendor needs to apply to a conformity assessment body (CAB) who will assess compliance against the eIDAS requirements for qualified trust service providers and qualified trust services. The CAB will then produce a conformity assessment report, demonstrating how the requirements are met and submit the resulting conformity assessment reports to the supervisory body. For example, Post and Telecom Authority (PTS) is responsible for carrying out supervisory activities under the eIDAS Regulation in Sweden.

For more information about atsec’s service for eIDAS, please visit:

https://www.atsec.se/service/eidas/index.html

“You’ve grown so much!” – atsec’s 20th Birthday

by Andreas Fabis

During my almost 20 years with the company (first as a freelancer, then as an employee) I have seen atsec grow from a small, determined group of IT professionals in a crammed room full of computers into an international company with a well-earned, excellent reputation in the IT security world.

Growing from the first baby steps to corporate adulthood comes with challenges, set-backs and opportunities to learn. I would like to share the personal lessons that have stuck with me during my time with atsec.

The atsec website from 2000-2020

1. Value your colleagues
This is maybe my biggest take-away: foster an environment where colleagues value, respect and help each other. The lack of silo mentality and the willingness to support each other makes working at atsec such a great experience. Of course, you are expected to find your own answers, but knowing that your colleagues will have your back is wonderful.

2. Value your customers
I often have the pleasure of taking the first call with a new customer. Sometimes they have little to no knowledge about the complex technical and regulatory challenges that come with a validation project. I think it pays off to take the time to explain the process and answer "dumb" questions. And I have witnessed the length we go to as a company to not just get the rubber stamp for a report, but to help the customer make their products and processes better beyond the scope of a particular project.

3. Embrace change
Our company’s work is closely tied to international standards and government bodies. Changes to standards can’t be avoided. New regulations and laws are passed, and validation bodies’ processes are updated. I learned first-hand that the way forward is for the company to change as well. Instead of trying to keep things the way they were, we adapt and work with government bodies and international communities and give our input to help shape the new way. You can’t swim against a river for long, but you can decide which shore you want to land on.

4. Stay focused
This is one of atsec’s founding principles and a lesson I learned early on. Stay focused on your core competencies and expertise - in this case IT security - even when you receive tempting offers to extend your business.

5. Grow slowly
I am generally an impatient person, so I was impressed by the patience and care atsec takes when it comes to investigating new business areas and new locations for additional offices. I learned that it pays off to be fast and agile when it comes to the daily business, but careful when it comes to company growth.

6. Be the change you want to see in the world
This lesson is good for your personal life as well. I enjoy seeing atsec do things instead of waiting for someone else to do them. From the first Common Criteria Linux evaluation to starting the International Cryptographic Module Conference: atsec often takes the step (and the risk) of trying something new or doing the thing that needs to be done.

Happy Birthday atsec!
Here's to the next 20 years (at least)!