Computer security, or the lack thereof, has made many headlines recently. In this article we'll look at how bad things are and what you, as a software developer, can do about it. I'll help get you started or hopefully give you some new ideas if you're already doing some security work.
The need for security
2014 turned out to be the Year of the Security Breach. In the wake of the massive Target incident, we heard about breaches at Home Depot, Ebay, JP Morgan Chase, Staples, Sony Pictures, the European Central Bank, and others. The list of the world's biggest data breaches is long and varied.
Those breaches reported massive numbers of records exposed, 85 million in the US alone. The resulting monetary losses are equally disturbing. Target spent an estimated 150 million dollars on their breach, for instance. It is estimated that cybercrime as a whole costs hundreds of billions of dollars each year!
The situation is actually even worse than the long list of breaches indicates, because many companies don’t even know they’ve been compromised. According to the FBI director
There are two kinds of big companies in the United States. There are those who’ve been hacked by the Chinese and those who don’t know they’ve been hacked by the Chinese.
But don’t think only big US companies are at risk. Last August we learned that a Russian group hacked over 420.000 websites to gain access to 1.2 billion user names and passwords. Hackers now specifically target smaller companies, because they know people re-use passwords, and those smaller companies have smaller security budgets and more trouble attracting and retaining scarce security talent.
It’s easy to get discouraged by all this bad news, but that doesn’t solve the problem. We need to start taking security seriously. At this point, continuing to ignore security is just plain irresponsible.
Of course, many organizations are already doing something about security. But, judging from the headlines, it's no way near enough. Security is often the domain of a specialized department within an organization. That approach doesn't work; we need to build security in from the start. This means that we software developers need to loose the "that's not my job" mentality and get our hands dirty ourselves.
So what can you do?
What you can do to get started with security
Cybersecurity is a vast field that deals with topics as diverse as physical access tokens (like Disney’s MagicBands), video surveillance, networks, secure software development, identity and access management, virtualization & containerization, memory management, and law & industry regulations. You can’t possibly hope to become an expert at everything.
I'm not aware of any official growth path into the security field, so you'll just have to figure it out as you go. Start by reading some general books, like Software Security: Building Security In or The Security Development Lifecycle. That will give you a sense of the topics in the field.
The next step is to pick some low hanging fruit and get some quick wins. Where to start really depends on your prior experience. For example, I had used static analysis tools like PMD and FindBugs in the past and they helped me catch coding errors. Given that background, it makes sense to start with a tool like Fortify or Veracode.
These tools are examples of Static Application Security Testing (SAST) tools, which find common vulnerabilities by performing a deep analysis of your application without actually executing it. They can do this by looking at the source code (Fortify), or at the compiled code (Veracode). The latter allows you to include the third party components that you use in the analysis. The National Institue of Standards (NIST) maintains a comprehensive list of SAST tools.
Learn enough about a topic to get some real value out of it, but don’t go overboard; there are many other topics waiting to be explored. Topics that should be high on your list to familiarize yourself with are threat modeling and secure coding practices. Threat modeling gives you a sense of what attacks are possible against your application. This helps you catch design flaws and oversights that may introduce security vulnerabilities. Secure coding practices like input validation (I particularly like Domain-Driven Security because it improves both security and maintainability) and output encoding help prevent implementation issues that lead to vulnerabilities. The two approaches are complementary, so you should know about both.
For each topic you decide to learn more about, there are a host of resources available to get you started. Obviously there are books, articles, and blog posts to be read. For books, you could get inspiration from the Cyber Security Canon, a list of supposedly timeless, must-read security books.
To learn more about SAST I read Secure Programming with Static Analysis. If you can't spare the time to read a whole book, then maybe this summary article is helpful.
Of course there is Twitter, where you can follow security bigwigs like Brian Krebs or security news aggregators like DarkReading.
There are also online and classroom training courses to be followed, some of which are cheap or even free. SAFEcode offers free on-demand introductory security courses about topics like passwords, Linux file permissions, and Cross Site Scripting. Coursera offers a free sequence of courses where you learn to build and break a secure system. Security Tube offers more advanced security courses. I took a whole bunch of security courses offered by my company. (More on that below.)
Finally, there are some interesting security conferences to go to, like RSA Conference, Black Hat, Hack In The Box, and AppSec USA, EU, or APAC. Each conference has a different audience, so make sure to visit a couple of different ones to get a broader appreciation of the security field. RSA Conference is very broad rather than technical, for instance, while Hack In The Box goes into a lot of detail about breaking into all kinds of systems.
One very nice thing about conferences is that they let you meet the security community in the wild. The craftsmen among you will appreciate how much help communities can provide and how much fun it can be to be part of one. For someone starting in a field, it’s very helpful to compare notes with other novices, or to run into someone willing to mentor you. I was very lucky to find a good mentor early on, and that really sped up my journey. Thanks, @AppSecDude!
OWASP is a good example of a community in the security field. They have three sub-communities, one specifically targeted to developers (called Builders). But learn about the Breakers and Defenders too, because it will change your outlook and make you more effective as a result. Your chances of catching an attacker are vastly improved if you can learn how to think like one.
Communities are only as strong as the contributions made by its members, so it’s important to give back. As you’re starting out, you may think you know very little, but even then it’s valuable to share. I blog about security and other topics at securesoftwaredev.com. It helps to organize thoughts, which is crucial when learning. You may also gain insights from comments that readers leave. Finally, you’ll get the pleasure of knowing that there are many others out there starting with security who would benefit from seeing they are not alone.
You may even already have a security community in your company. For example, EMC has a Product Security Office, which provides me with a personal security adviser and all kinds of security-related training, documentation, and tools. They also engage employees via our internal collaboration environment and handle the external communication part of incident response.
If you’re not lucky enough to have a security competence center in your organization, you can always gather some like-minded people and start one. I’m sure you’ll learn a ton and make some new friends along the way. Such an effort will probably require some organizational backup.
In fact, most of the things you can do to improve the security of your work product will benefit from a broader organizational approach. So how do you get management buy-in?
What you can do to help your organization get started with security
Given all the recent breaches, chances are that security is already a C-level concern in your company. You can take advantage of that sentiment and move your organization to a more mature approach to security.
At EMC we follow Microsoft’s Security Development Lifecycle (SDL), with a few minor changes. The SDL describes various activities (from training and requirements all the way to release and incident response) that you should perform during software development to build security into your application. They also offer a free threat modeling tool.
The SDL prescribes a number of security activities, but it doesn’t provide a structured way to phases these practices in based on your priorities. It is therefore probably easier to start with a security maturity model that guides you a bit more. The two most common ones are the Building Security In Maturity Model (BSIMM) and the Software Assurance Maturity Model (SAMM). Either will work just fine and they can even be mapped to each other. I will focus on SAMM here.
The Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization.
The SAMM guide assumes four business functions in developing software and assigns three security practices to each of those:
For each practice, three maturity levels are defined, in addition to an implicit Level 0 where the practice isn’t performed at all. Each level has an objective and several activities to meet the objective.
To get a baseline of the current security status, you perform an assessment, which consists of answering questions about each of the practices. The result of an assessment is a scorecard. Comparing scorecards over time gives you insight into your organization’s evolving security capabilities.
With these building blocks in place, you can build a roadmap for improving your capabilities. A roadmap consists of phases in which certain practices are improved so that they reach a higher level. SAMM provides presentations and templates including roadmap templates for specific types of organizations to get you started quickly.
How DevOps can help security
Most of the resources described so far have been available for a while, and yet security breaches are rampant. So what is preventing organizations from developing secure software?
One reason may be that security people see it as their duty to say “no” a lot, in an attempt to block insecure systems from being deployed into production. But today’s fast-paced world of the third platform has little patience with naysayers that get in the way.
Testers used to be in a similar position, trying to block bug-ridden systems from being deployed into production. But many of them are now part of Agile teams and work with developers to prevent bugs from being introduced using techniques like Behavior-Driven Development (BDD).
People working in Operations also used to take this stand. But in some companies, they are now part of a larger DevOps team where they work with developers using techniques like Test-Driven Infrastructure to make sure from the start that applications can be deployed flawlessly.
Security people need to make the same cultural shift as testers and operations people have made/are making. The focus should be on collaboration and building security in from the start in an efficient and scalable manner.
Some people have pioneered such approaches under names like rugged software, DevOpsSec, or SecOps. This movement is growing in popularity, as demonstrated by the first ever DevOpsSec day at RSA conference this year.
And for good reason. Security and DevOps are a match made in heaven. Security can learn from DevOps how to work with rather than against developers to achieve the business’ goals. Conversely, DevOps needs to pay more attention to security.
There are many other advantages that DevOps can bring to the security table. The JPMorgan Chase breach, for example, was made possible because out of all their servers, a small number didn’t have two-factor authentication installed. If all servers had been deployed with DevOps-style configuration management that couldn’t have happened.
Maybe there is hope of stopping the flood of breaches after all.
About the Author
Rémon (Ray) Sinnema is a hands-on software architect based in the Netherlands. Since joining the OASIS Technical Committee that defines the eXtensible Access Control Markup Language (XACML) standard, Ray has been focusing more and more on security. His other professional interests include REST and DevOps. He is ApiSecRay on Twitter and blogs at securesoftwaredev.com.
