Submitted
By Isaac Potoczny-Jones
Perhaps your commute to work each day requires that you drive over a bridge. Imagine if the engineers and planners constructing that bridge focused solely on its design and aesthetics, and ensuring it had enough lanes to meet anticipated traffic volume—leaving the question of whether the bridge was sturdy enough to not buckle under the weight of vehicles until after construction was completed.
For drivers this would be a rather absurd—and frightening—way to build bridges, and yet, this is often exactly how organizations approach the software development process when it comes to cyber security. They build software and products to work as intended, and then after the software is out on the market adopt a reactive “patch and pray” philosophy to mitigate any security vulnerabilities. The fact is that if an organization is trying to figure out how to secure their commercialized software product, it is too late.
Organizations must get in front of software security issues by analyzing the full spectrum of risks and developing a secure product line roadmap—for example, correct codes upfront—with security in mind from the start. By doing so, organizations are not just building products that work as intended, but that work only as intended.
For businesses—whether it is a startup or global multinational—seeking to build cyber security into the software development process from the start, there are several strategies to consider.
Don’t Fall into MVP Trap
The market demands of software development often strongly encourage leaving security to the end for a variety of reasons.
Many companies want to validate a market before investing in a product, so the “minimum viable product” (MVP) approach might leave out serious thinking about computer security.
The risk of getting attacked is lower at the beginning of a product’s lifecycle, so companies can validate a product by getting market traction even if it has vulnerabilities. There are numerous exceptions to that, of course. Major brands with significant products will get attacked right away.
The bar is relatively low because there are so many vulnerabilities out there. To be secure according to an industry standard is not a huge investment, and anything more advanced is typically implemented after the fact.
Ultimately, it comes down to a false assumption that your “minimum viable product” will not attract serious attackers, but this presumes that you do not get traction or media attention, which is a lose-lose proposition—either your MVP is a failure, and so security doesn’t matter, or your MVP is a success and you will get attacked.
Don’t Narrow Focus to Functional Software Requirements
Your software is expressed purely in terms of “what it should do” (functional requirements) and you have no security requirements, goals, or models of potential adversaries. While Agile methodologies don’t discourage security by any means, their emphasis on working software tends to underplay non-functional requirements like security. Non-functional requirements go beyond what a system should do and describe what the system should be.
It should be secure, protecting yourself and your clients from disclosure of sensitive information. It should be resilient, protected from denial of service attacks. At the early stage, don’t worry so much about massively distributed attacks, but watch out for situations where a small attack can cause an outsized amount of CPU use or network traffic.
It should be smart. Protect your product against the most likely attacks. The “OWASP Top 10” clearly describes the types of attacks that Web-based systems will face. These should all be addressed in your architecture and implementation.
Avoid ‘Penetrate and Patch’ Approach
Penetrate and patch is a style of vulnerability management that waits for attacks to happen before secure development is implemented. Similar to the above, this is often about a focus on features over security and makes a risky assumption that the first penetration won’t be catastrophic. In reality, if all of your users’ intellectual property, credentials, or bitcoins are lost, your product might immediately become a hot potato and never be able to recover.
Recognize Fundamentally Insecure Products
Entrepreneurs love a product that’s never been built before, but sometimes a product has never been built because there’s no way to build it securely.
Some white-hot social networking applications grew in popularity based on the premise that the user’s photos/videos/messages would be deleted immediately after being viewed. Unfortunately, this assumes that the app on the receiving user’s phone will “do the right thing.” That’s never a good assumption in security. Client/server systems can’t leave security in the hands of the client because the client can always be replaced with a malicious version. In many cases, there is no way to guarantee that client software won’t save a picture. The lesson here is not to make security claims that are impossible.
Never Trust a Mobile or Web Client To…
There are several things you shouldn’t trust a mobile or Web Client to do. Such as, keep secrets from the user who is in control of the client software. You can’t store the server’s crypto keys on the user’s client and expect that no one will ever find them.
Submit well-formed and trustworthy information. Anyone can modify JavaScript to send anything they want.
Perform actions that the user doesn’t want it to perform. Anyone can write a chat client that doesn’t respect the “delete this picture” or “don’t copy this movie” commands.
Only make server requests that are available in its user interface. Assume that your Web APIs will be exercised to their full extent by curious or malicious attackers.
Instead, implement robust security on the server, and trust the client as little as possible, even if your team developed it.
Ensure Organizational Accountability
While many organizations have cyber security professionals with clearly defined roles, responsibility and accountability can get muddled when it comes to the product development process. Organizations with strong and structured enterprise-wide security processes must mirror this approach for the product development process up and down the hierarchy chart by having concise answers to several key questions.
Who determines what high-level organizational risks are important, and how do those risks get translated into product requirements? How do you verify that those requirements will address organizational risks, which is particularly challenging because there are so few cyber security professionals able to grasp issues at the technical and the organizational level? Who is accountable for making sure developers are trained in security? Who is accountable for ongoing maintenance and patching? Who is accountable for handling incidents after you get breached?
Understand How Customers Will Deploy Software
As previously referenced, software is too often developed to work as intended, rather than only as intended. The result is software that works functionally but not securely. To build software that works only as intended, a vendor must first gain an intimate understanding of how customers will deploy software under a broad range of use cases that change rapidly and dynamically.
For example, as automobiles shift from being non-networked vehicles to highly connected technology-driven devices, automakers and supplier vendors must build cyber security capabilities that address this product evolution.
There are other factors to consider in understanding how customers might deploy software.
Does the customer have a different trust model than you do? Such as, they don’t or can’t deploy encryption of data in transit when your system relies on it.
The operator of the system is not trusted and your system is not protected against insider attack.
Your client can’t store data in the cloud.
You design the system to live within the firewall, but it gets converted to a cloud-based product.
The environment is not physically secured, so potential adversaries can have access to the hardware that your product is running on.
Forethought
Cyber security should not be an afterthought in the software development process; it should be the first thought. As applications, systems and devices increasingly fall victim to hacks, vendors may be tempted to assume that business users and consumers have become desensitized to the problem. That adding two-factor authorization or offering three months of credit monitoring service will somehow wipe the slate clean with no damage done to brand perception, customer growth, and revenues. This is not the case. Building cyber security into the front end of the software development process is critical to ensuring software works only as intended. SW
Isaac Potoczny-Jones is research lead, computer security, Galois, which specializes in the research and development of innovative security technologies for military and commercial organizations. Earlier this year Galois demonstrated software for the Department of Defense that prevented hacking of drones, and that is applicable for preventing hacking of automobiles and other devices.
Aug2015, Software Magazine
Sources:
OWASP top 10, https://www.owasp.org/index.php/Top_10_2013-Top_10
