Security assurance – challenges and 5 tips for a safer connected future

Back in 2015, a successful attack on Ukraine’s power grid resulted in a widespread blackout, leaving nearly 230,000 residents without power and plunged into the cold and dark in the middle of winter. This attack was the culmination of months of preparations, planning, and organization. Although the power was able to be restored within six hours, the control centers were still not fully operational more than two months after the attack.

Today, the highest risk cybersecurity threats and attacks aren’t coming from small-scale computer-genius hackers in a poorly lit basement. We’re facing large, extremely knowledgeable teams of experts – highly organized, well-resourced, and in some cases state-sponsored organizations constructing highly sophisticated targeted attacks.

At the same time, critical infrastructure like power grids, financial institutions, and even governmental networks are all becoming increasingly connected and more reliant on IT systems. To enter the next era of virtualization and cloud infrastructure with confidence and keep our industries and countries up and running, we need security measures that are just as cutting-edge as the technology they protect. And for that, we need to define the requirements of security assurance.

So what is security assurance?

Security assurance is a process in which arguments can be presented about underlying risks associated with products, software or services. It can be used to certify a particular product or service with a specified level of security, according to the given standard or against a certain profile. There are many security assurance tools, techniques, and metrics available. One of the most often used is the Common Criteria for Information Technology Security Evaluation, or Common Criteria (CC). CC uses an increasing scale of evaluation assurance levels, balancing the level of assurance with the cost and feasibility of acquiring that degree of assurance.

Any vulnerability testing cannot prove that a system has no vulnerabilities – it can only prove the system is secure (or not) against the attacks it’s tested with. Similarly, security assurance cannot guarantee that a product is risk-free to use – but, if done correctly, it can provide a strong basis of confidence that it is secured to a certain point.

There are two parts to security assurance to consider: development and evaluation. The developer has to build the product with security in mind, and then the evaluator has to verify it. There’s a common misconception that an evaluator can make sure that the product will be secure. But a sommelier does not improve the wine – they only taste it. They may say what's wrong with it, but they cannot change the way the wine has been made. And here we meet one of the big challenges facing the evolution of security assurance.

One process, two worlds

Effective security assurance relies on the close collaboration of development and evaluation – two distinct worlds that, at the time of writing, are simply not communicating with each other in the way they need to. Many vendors are developing and maintaining things in a secure way and doing excellent work when it comes to testing, test coverage analysis, and following good security principles. But these efforts aren’t recognized, or are often not considered by those doing the verification, either because design is not a part of the evaluation criteria, or because it wasn’t covered in the documents they’re using for evaluation.

Take secure design principles, for example. You want to have privileges, isolation, separation, different security domains, trusted execution environments – all of which are very good initiatives that contribute greatly to security. But in CC, for example, these only come in at level five evaluation assurance. For levels one through four, you don't have to design the product in any specific way. But once the product is built, it’s much more difficult, if not impossible, to change how it was designed.

We also see the reverse when a vendor requests a product evaluation. It’s common to hear: “We have designed our product according to common criteria”. But CC is not a design method. It's a verification method. So sometimes that the understanding of assurance and what it means becomes isolated in these two worlds.

Compliance testing vs security analysis

Another division needing to be addressed is the two approaches being taken to security assurance: security analysis and compliance testing. In the US, vendors are largely looking for compliance testing, so this is what standards such as FIPS 140 (which is used for crypto modules) mostly focus on. Of course, some vulnerability assessment may be done as well, but it's often very limited. Compliance testing is usually more objective and gives a very well-defined result, but it’s less flexible when it comes to product types and functionality.

Standards such as CC involve more open-ended security analysis. They can verify the absence of exploitable vulnerabilities through an active search for vulnerabilities and an analysis if they could be exploited. This approach provides more flexibility, but also requires more evidence from the vendor and more skills from the evaluator. But the CC standard itself doesn’t state the specific requirements for a certain evaluation – it still requires Protection Profiles and Security Targets. And all CC evaluations conducted in the US use NIAP-approved Protection Profiles, which also only require the performance of compliance testing.

With government-developed requirements for compliance, those defining the requirements might not have recent development experience. They may not know what's current and what’s possible today, so the requirements will be limited and not allow space for innovation. On the other hand, if you take a more flexible open-ended approach, it’s hard for a vendor to find good developers who understand security well enough, and you also need well-trained people conducting the assessment.

There are no simple answers. As author and journalist H.L. Mencken said: "For every complex problem, there is a simple solution. And it’s always wrong."

So, what are some ways we can work towards improving security assurance and prepare our systems for the threats to come in the future?

Tip 1: Find a balanced approach

As mentioned, with secure development and maintenance of products, organizations can do a great deal of work toward ensuring the product’s security. This should be considered in the evaluation, providing a more integrated and holistic approach. Assurance measures in the development cycle should be better recognized, and assessments should promote development assurance.

In the mobile network industry, regulatory demands on security assurance for 5G have led to standardized specifications. The Network Equipment Security Assurance Scheme (NESAS) is an industry-wide security assurance framework, jointly developed by 3GPP and GSMA, which defines security requirements and an assessment framework for secure product development and product lifecycle processes, and uses security test cases for the security evaluation of equipment.

This framework could provide a good benchmark for wider use in security assurance, as it looks not only at the end products but also at the way they’re developed. We need to find a way to optimize – to find a balance between the level of assurance and efficiency in development and evaluation, identifying what levels are necessary and considering the level of risk involved with the systems or infrastructure the product is for.

Network Equipment Security Assurance Scheme (NESAS) is a voluntary scheme applicable to network equipment designed to support 3GPP defined functions

Tip 2: Collaborate and communicate with transparency

To achieve a more balanced approach as described above, we need to see more communication and training so that developers and evaluators can understand each other better and work together to optimize the process. Software engineers often build in many layers and at high levels of complexity, meaning evaluators with little or no development background will be poorly equipped to evaluate the value of the developers' contributions. However, it’s important to remember that requirements like development expertise for evaluation will come with a higher cost.

Regardless of the approach, when undertaking evaluation, developers need to be transparent and communicative. Tell evaluators what you’re doing and how you’re doing it. Don’t try to create an alternative reality for auditing – if the evaluators offer suggestions for improvement, they want to improve your real processes and not artificial ones that have been submitted.

If security assurance is to take a more holistic approach, we need to find a compromise that accommodates the needs of both the developers and the evaluators, while remaining efficient and cost-effective for the level of assurance required. We need to clarify what the roles and responsibilities should be in this process. Right now, confusion remains over who should do the testing or vulnerability analysis. But both sides must be involved – they just have different roles to play in the process.

Tip 3: Prepare for complexity with layers and diversity

The sophisticated attackers we face today are constantly looking to inject vulnerabilities or malware into the supply chain. Unfortunately, many companies aren’t currently putting enough emphasis on supply chain security. While it isn’t cost-effective for most companies to build up their own supply chain for complex systems, leaving them reliant on third-party components or software, diversity can offer a work-around solution. You shouldn’t put trust in just one service or component, but you might be able to achieve sufficient security assurance by combining different security layers from different suppliers or nations – one from the US, one from China, for example. For your system to be broken, they then need to talk to each other – and most likely, they won't.

The same can apply to encryption, where even commercial products can be used for classified systems by combining layers, such as using an SSH layer together with a TLS layer. Right now we have a monoculture of open SSL, a monoculture of Windows, even all the web browsers have more or less the same core engine in them. This means they share some of the same vulnerabilities, and if one is breached, they all are – we have a whole infrastructure problem. Designing systems with combined layers can provide a realistic alternative. The system can be trusted up to a certain point, then you build a service on top of that to add more complex functionality. Doing this not only can result in less work to achieve the assurance, but you may also find fixes are more readily available because you are using commercial products.

Newly emerging technology like cloud and virtualization – which will become commonplace as 5G rolls out across industries – means applications could be running in the cloud, at the edge, at the core data center, or even be distributed across all of these. Control will become more diluted, impacting security assurance across the telecom industry and adding to the complexity of an already complex problem.

To resolve this challenge, we need to address the interactions between different layers of the products: hardware, software and virtualization. We need to build trust in a different way, making sure we don't have any critical side effects. With this new infrastructure, hardware developers don't necessarily know what will run on top of it. So they try to optimize it, and as a result end up with optimizations that could be exploited by an attacker. Of course, this can be fixed, but it won’t be fixed in the hardware, only in the software. The important thing is when you're building an application at one level, you make assumptions about what will run on top of it. And these assumptions may not be completely valid, as we don’t know for sure how these things will behave.

We mentioned multiple layers of encryption and security services earlier – we have to do the same thing here. You add a layer that can verify its integrity and protect itself on top, but you should have a clear understanding of what assumptions you’re making on what is underneath. If you understand this well, you can do it securely. The real problem will be if people are rushing too fast and don’t take the time to consider the impact and side effects it may have on their systems.

Tip 4: Pick an assurance level that suits you and your product

It can all seem overwhelming, so it’s important to remember that an organization doesn’t always need to (and often shouldn’t) go for the highest possible assurance level from the start. It depends on the customer and the domain where the product is being deployed. If it’s in critical infrastructure, and it’s the networking equipment or the sensing or control capability, then you might not have a choice but to go for the higher level. Either way, you should ensure it's not negatively impacting the security of your critical infrastructure.

The assurance level must also be meaningful and relevant for the customer. You don't want to buy equipment intended for high-security use and carry out low assurance, as potential (or even worse, exploited) vulnerabilities can tarnish your reputation. Of course, a company may choose a high assurance level in a premium product, to impress the customer or to leverage in marketing to instill confidence and trust. But in general, a better approach is to learn by doing – starting at the lower end, and ensuring you have requirements that can scale.

A company looking at non-critical infrastructure might be looking to start with assurance level four, for example, which means reviewing source code. But looking at it, an evaluator might suggest that level two is a better place to start from, taking into account the effort and the cost involved. The higher levels can be considered later. Not only will the company learn for future development, they’ll also be in a better position to take on additional evaluation and assurance levels as needed.

Tip 5: Leverage the technology

There are always tradeoffs when it comes to security assurance, and one of the biggest is that if you want to do a thorough security inspection of any device or any software, it's costly – especially at the higher assurance level. The tools at hand are also costly because of a lack of automation – and now with virtualization, it's becoming even more complex.

The good news is that in recent years we’ve seen a surge of interest in vulnerability research. People are producing more advanced techniques to handle vulnerabilities, to find security vulnerabilities in firmware, in software and so on. We need to see more of this kind of research, as the results are what will enable us to introduce much more automation and leverage AI. These technologies will be crucial for handling vulnerabilities in increasingly complex systems, and making the security assurance process more cost-effective, efficient and scalable.

The time to act is now

As we head into this new frontier of security assurance, we need to keep thinking about what we're doing and why we’re doing it. We shouldn't just take a standard and copy it or tick the boxes – we need to keep up with the latest research and learn from history, to build something that makes an important contribution. Industry initiatives in the security assurance field have slowed since the late 1980s, with service operators not pushing as much for security assurance. But with the kind of attacks on infrastructure we’ve seen already, it’s likely a major attack will come. And when it does, regulators and government agencies will start pushing very hard for security.

But government agencies are not the ones who are best placed to act on this. We already see many situations where industry has not participated, and they end up with requirements that are impossible to implement. We need to be proactive and try to prepare for this situation. Industry needs to take control and get involved in defining the requirements. Through industry participation and collaborative initiatives, there can be immediate feedback on what the requirements are and how they can be implemented. And we can build security assurance processes that ensure our systems are secure by design, well-evaluated and capable of standing up against whatever new challenges lie ahead.

Learn more

Read more about security standards and their role in 5G mobile network security

Discover the vital part security has to play in mobile networks, with our guide to 5G network security

Explore the holistic efforts involved in ensuring a secure 5G system, with this overview of the 3GPP 5G security standard

Find out more about cyber network security and the four pillars of 5G security