Welcome to this lecture on Software Security Assurance. In it you’ll learn about what Software Security Assurance is, and look at the various design principles that can help you in secure software design.  

We’ll focus on:

• Implementing and managing technical processes using secure deign principles, 
• Security design principles, 
• Designing the network, 
• Fuzzy boundaries, 
• Keeping control of data, 
• and Separation of systems as a way of reducing risk. 

Let’s first define what we mean by Secure Design Principles. 

Simply put, we are looking to engineer a system by first looking at user requirements and the way in which the system can be architected, to produce an end product that works. This engineering process is applied throughout the life cycle of the development of the system. A security architect is there to ensure that security is baked in to the development life cycle, whilst also aiming towards the goal of a working end product. 

Firstly, let’s consider the weakest link. As with a chain, systems are only as strong as their weakest link. You must ensure that you don’t take the time to design a system that is 95% secure, only to leave a weakness in place that can be easily exploited, thus defeating all our other security features. As defenders, we need to be lucky all the time whereas the attackers only need to be lucky once. This is a somewhat unfair equation but is the harsh reality of cyber-security. On screen you can see examples which you may not consider when designing a system, but which could be vital cogs in the machinery of your overall security position. 

The term ‘defence in depth’ refers to an approach to security that doesn’t rely on just one line of defence. The more layers of defence that we can design into a system, the more difficult it will be for an attacker to compromise the system.  

You need to assume that you will be attacked and that an attacker with the right skills will be able to compromise at least part, if not all, of your system.  This scepticism about your ability to defend yourself is vital, as it helps you to think about your defensive strategy. On screen you can see many different layers that you can think about applying to your system. You can pick and choose from this list, along with other layers that may be available, but more layers of protection is always preferable.   

This is the focus area for the security architect – they will consider exactly which of these layers is appropriate to your system design, and exactly how these layers can all be pieced together to ensure that they work seamlessly together. If any of the layers interferes with the correct operation of another layer, then your defence in depth approach could have inadvertently created a weak link. 

When designing a system, we rightly concentrate on how it should work when everything goes according to plan. After all, we are designing a system to achieve a specific task.  However, it is just as important to consider what will happen when things go wrong – for instance, when a user presses the wrong button or sends the system some incorrectly formatted data. If you don’t think about this during the design phase then you won’t know we how your system will react. This uncertainty is an opportunity for an attacker. 

To mitigate against this, ensure that ‘out of design’ actions are handled gracefully – errors will result in the operation of specifically designed error handling code, rather than unknown and unforeseen actions occurring. 

Your system should be designed to run with the minimum system privileges required. Running any applications with excessive privilege means that any malicious code that is attacking that application will also be running with elevated levels of privilege, giving it a larger scope for causing damage. 

Finally you need to consider how privileges are granted for users of the system. For instance, how to employ a system of usernames and passwords, or considerations like including further authentication methods. 

You should always look to ensure that your systems are designed to be as simple as possible – the more complexity you build into something, the more scope there is for errors to creep in. Keep systems simple, but always ensure that they are secure. 

It is very easy to re-use mechanisms that have already been designed – after all, why re-invent the wheel, when we have readymade code or processes that can accomplish the task at hand? However, this mentality does have some problems with it.  

A compromise of one highly shared mechanism can lead to multiple further compromises down the line. By all means re-use concepts or code but ensure that each process can have its own version. Finally, always assume that your system has security flaws and the environment is insecure. 

It is tempting to think that your organization has little of interest to any attacker, and you can afford to be less concerned about security. However, this assumption is false. No matter how obscure you may consider your organization to be there will always be someone that could look to attack you – even if only for fun or the challenge. 

Systems should be protected to the best possible standard that you can manage, afford and that the security architect says you need. 

Checking the access rights of users should not be a one-time effort – checking them only at login will generally not be enough. Preferably, you should check them every time they look to use their access rights. This way you will have a better chance of catching any suspicious activity that has occurred since they logged in. 

Throughout this video I have talked about the need for secure systems extensively, but if that security impinges too greatly on the user experience users will find ways to circumvent your carefully designed security measures. This is a difficult balance to strike and you should take any guidance on this issue from your security architect. 

A flaw in one layer is highly likely to be replicated across all of the other layers supplied by one vendor, leading to greater opportunities for attackers to penetrate deeper into your systems. 

You should instead consider using different vendors for the different layers – it is the job of the security architect to ensure that all of these different products can work in harmony. 

Give users the option to use different technologies in their everyday work – for instance, use the Google Chrome browser for any web based applications that are used internally in your organization, and the Firefox browser for accessing external websites. 

One of the more recent security design problems has been the loss of the distinct boundaries around organizations. In the past, corporate machines and systems were contained within boundaries, allowing us to create strong perimeter defences.  

Nowadays, the advent of flexible working and mobile connectivity means that corporate machines are outside of boundaries, and looking to connect back into the systems. To accommodate this you need to create appropriate gaps in your external defences. You also need to consider how to secure machines that are no longer under your full control. 

Bring Your Own Device, or BYOD, refers to the practice of allowing users to connect their own devices to your systems and brings a number of potential security issues with it. The organization will have little or no control over the configuration of these personal devices, which means that you will have a limited perspective on what their security position is.  

BYOD are accessing your organizations data. It is therefore important to understand how you can control what happens to your data once it is accessed outside the boundaries of our organization. 

This includes thinking about allowing users to use their own storage devices, such as USB sticks. These types of devices have huge storage capacities, and are incredibly small so it’s important to make sure that you have appropriate controls in place to stop a malicious insider from plugging in their own USB stick. 

There are other ways of creating a layered approach to your security. Let’s begin by separating out the different application layers we have. The web server will host your customer facing website, but the data that your customers rely on can be held on a completely separate system.  

This alternative system can have appropriate protective systems in place to ensure that a compromise of the website does not automatically lead to a compromise of your database. 

You can also ensure that different business functions within your organization are only given access to the systems they require – the sales team do not need to have access to the personnel system for instance. 

A good security position requires careful planning and implementation, and will ensure that people are only ever given access to those systems or datasets that are essential for them to complete their tasks. 

This brings us to the end of this video.