Perhaps the most common piece of security advice you’ll ever get is to make sure you’re running updated, patched systems. And this is good advice given how systems are designed and implemented. You only need to look at the recent WannaCry outbreak to understand how a single vulnerability can wreak havoc on a global scale.
But what’s less talked about is something F-Secure Principal Security Consultant Olle Segerdahl gave a talk about during last year’s T2 Conference – how to develop systems that are secure in the first place.
In a nutshell, the problem is that many companies treat security as a secondary concern. It’s an add-on to a product or service. As Olle points out, companies tend to develop something, and then test it to see if it’s secure enough to take into use.
There are various ways you can test the security of a particular system or product. Typically, companies will run a series of security (penetration) tests on a nearly finished product to find problems. Then, they simply fix any problems identified by the tester and move on.
Penetration tests are valuable, but they have limits. Their effectiveness depends on how much time/money companies spend on conducting the tests, whether they’re done once or periodically, what exactly the tests include (or more importantly, exclude), and more.
According to Olle, testing the security of something after it’s been built isn’t enough to answer the million-dollar question: is the system secure?
Tests can provide a useful list of bugs to address, but finding and fixing bugs isn’t the same thing as saying a system is secure. As mentioned above, there are method and resourcing issues that can limit the effectiveness of tests and increase the chances of missing serious security problems. That leaves developers reacting to security issues rather than proactively minimizing problems. And having cyber criminals stumble across vulnerabilities that the tests missed can expose both product vendors and their customers to serious problems.
Making a case for system security
So how can you find a reliable answer to “is this system secure”? Or even better, “will it cost an attacker more to break in and steal the information than the information is worth”?
According to Olle, a safety case is a practice from the transportation industry that exemplifies a good approach to secure system development. A safety case is a type of structured argument intended to demonstrate that something is safe to use underneath predefined conditions, and widely used to help establish that a vehicle or certain piece of equipment is safe for people to use in the way they’re meant to use it.
During his talk, Olle highlights assurance cases – a generalization of safety cases – as something developers can use. This involves arguing that a statement about a specific property of a system is true – an approach Olle refers to as “security assurance.”
Using this approach, a development team starts with a security requirement – such as that a system verifies the identity of a user before sharing sensitive information with them – and then creates an assurance case that persuades people that the system possesses this property. The assurance case would consist largely of supporting evidence provided by developers, testers, consultants, and others involved in its production so that it’s factual and provides an accurate description of the system’s security.
But more importantly, the assurance case can and should be produced and updated as the system is developed. By producing the system and assurance case concurrently, the two can inform each other, essentially synergizing security requirements with the system design and implementation. The development work itself would include several different steps to facilitate this process: architecture analysis or “threat modelling” to find out which risks the system needs to mitigate using security controls; security engineering work to inform the system design and validate that the right security controls are implemented; and security verification of the implemented controls to provide evidence that they are indeed in place and effective.
This process would eliminate the compulsion to defer security work to the end of the development phase, at which point the only option is to rely on testing a finished product to find out what’s wrong with it – a process that can produce unpredictable results (such as unforeseen costs, delays, or a failure to find shortcomings).
Essentially, a security assurance approach allows companies to answer the question “is the system secure?” by showing that developers have designed and tested the product in a way that minimizes the risk of security vulnerabilities. This is how you can make sure you that security has been “built in” and not “bolted on” as an afterthought.
The IoT could use some “security assurance”
It’s interesting to reflect on the flood of insecure internet of things (IoT) devices when considering the benefits of the security assurance approach. Researchers and consultants at F-Secure have seen numerous instances of vulnerabilities in webcams, routers, and storage devices over the last 12 months.
Many companies with no experience in software development are now manufacturing smart (or vulnerable as Hypponen’s Law states) gadgets. And criminals are learning how to exploit these gadgets, such as in last year’s unprecedented DDoS attacks.
Some experts have suggested that nothing short of new regulations will compel IoT device manufacturers to make security more of a priority. But the security assurance model advocated by Olle during his talk could be a cost effective alternative to the heavy handedness of regulations by making security more practical and manageable for developers.
There might not be a silver bullet for security, but everyone will benefit when security becomes more than just an afterthought.
[Image by Alan Levine | Flickr]
Categories