PM Articles > Alan S. Koch > Secure Software -- Don't Be the Next Target!

Secure Software -- Don't Be the Next Target!

by Alan S. Koch, PMP

"We have a firewall. And strong passwords. And we encrypt sensitive data. And we use a virus-scanner. And... Of course our systems are secure!"

We wish! Just a glance at the news is enough to send shivers up your spine. (Just substitute your company's name for the most recent news-generator.) The bad guys are all over, and they're really smart. What more can we do?

The good news is, there's a lot we can do. According to Software Security guru Gary McGraw, most of these terrifying exploits involve simple software issues -- issues that every software development project can address. If we keep security in mind as we address requirements, design, coding, and testing, we can head off the defects that hackers are intent on finding and exploiting.

McGraw provides guidance for software development teams in the form of his 7 Software Security Touchpoints:

  • Risk Analysis
  • Abuse Cases
  • Security Requirements
  • Code Reviews
  • Risk-Based Security Tests
  • Penetration Testing
  • Security Operations

Let's take a quick fly-over of those touchpoints to get a feel for what we could be doing on each software project.

Requirements Touchpoints

Predictably, it all starts up front in the project chartering and requirements phases. During these formative stages of each project, we should be identifying the security issues that are pertinent to the system we are building.

Risk Analysis -- The heart of building secure software is applied risk management. We're not talking about project risks here. Rather, we mean analyzing the security risks that we need to keep in mind throughout the software project. What threats do we need to be concerned about? In what ways may we be vulnerable to those threats? What needs to be protected? And how much effort and time is it worth to protect it?

We can't protect everything against all possible threats. So we must determine where to focus our efforts to be sure that our really important security risks are addressed.

Abuse Cases -- In almost every security breach, there is someone who is consciously trying to exploit the system. These actors may or may not be people that we intend to be using the system. But either way, their exploits will involve some form of abuse of the features and functions of the system.

So, just as it is useful to define Use Cases to flesh out the intended operation of the system under normal use, we must also consider the Abuse Cases -- the actions that abusers of the system could take to misuse or exploit the system's capabilities.

Security Requirements -- Based on the Risk Analysis and Abuse Cases, we can define specific capabilities and qualities the system must include to ensure that the risks we worry about are mitigated and the Abuse Cases we can foresee have been addressed.

These security requirements will go far beyond merely encrypting vulnerable data. They will also include checks and balances, separation of concerns, double-checking critical operations and many other features.

Design Touchpoint

Architectural design, system design, and detailed design are the places where our Security Risks and Requirements are addressed.

Risk Analysis -- Again we focus on risk. But in the context of design, our risk analysis has a different slant. Here, we look at the architectural and design decisions we are making and assess their vulnerability to attack. McGraw reports that many attacks exploit weaknesses that are commonly designed into systems. And although we can't know the vulnerabilities that will be discovered in the future, there is much published information available about known exploits.

So in addition to figuring out how we will implement our security requirements, all of our design work must be analyzed for the ways in which it mitigates (or makes us more vulnerable to) our key Security Risks.

Coding Touchpoint

Every software developer makes mistakes resulting in bugs. Many of these bugs result in the system not functioning as intended, rendering the system unfit for use. But some bugs result in security vulnerabilities, rendering the system vulnerable to abuse. (The buffer overflow is so well known that it should have been eradicated by now, yet it is still a very common security bug.)

Code Reviews -- Since many security bugs are well known, reviewing code for them is a natural defense. And with the code analysis tools that are available, this type of review is best automated.

Testing Touchpoints

Although Design Risk Analysis and Code Review will eliminate many security issues from our systems, these touchpoints can't find all of the security vulnerabilities that may exist. So special security-focused testing is also required.

Risk Analysis -- The Risk Analysis that was done during the Requirements and Design phases continues during testing. We need to keep our security risks clearly in sight, and focus our testing to find any vulnerabilities that may have been introduced by the design and coding choices that were made throughout the project.

As with any other kind of testing, security testing must go beyond merely ensuring that the product does what it is supposed to do. It must also ask what can go wrong and look for evidence that things may not be right.

Risk-Based Security Tests -- Of course our test plans must ensure that each and every Security Requirement has been implemented without fault. But we must go beyond mere functional testing. Our Security Risk Analysis provides the basis for planning effective security testing that uses known attack patterns and Abuse Cases to probe for vulnerabilities and features that could be exploited.

In addition to planned and scripted security testing, testers should be allowed a portion of time to "follow their noses." Based on the Risk Analysis that was conducted and Abuse Cases that were defined during the Requirements Phase of the project, good testers will be particularly adept at sniffing out unexpected vulnerabilities!

Penetration Testing -- Penetration testing (like performance testing) is a special class of testing that is performed by specially trained and equipped professionals after the system's functionality has been confirmed. Penetration Testers must be knowledgeable about the current state of the security industry and the vulnerabilities that exploits are currently aimed at.

Post-Deployment Touchpoints

As with other quality attributes of our systems, security must remain a focus even after the system has been deployed.

Penetration Testing -- As software exploits evolve, penetration testing must continue to ensure that newly discovered vulnerabilities and newly concocted exploits do not jeopardize the security of our deployed systems.

Security Operations -- Operational and Network Security professionals are a rich source on information on how to improve the security of our systems. Their feedback on each system we deploy should become input not only for future updates to that system, but also for improving our approach to any future software project we undertake.

The proof of the effectiveness of our secure software development practices happens in operation. This goldmine should not be ignored!

Knowledge about Security

It should be obvious that many of McGraw's seven touchpoints require security knowledge that most members of our development teams may lack. Education on the topic for all team members is quite valuable. In addition, it is worthwhile to have one or two people whose jobs include keeping up to date on the latest happenings in the quickly evolving field of software security.

McGraw's book Software Security: Building Security In is a good starting point, and his 22-page bibliography is full of pointers to other valuable sources.

Head-in-the-sand is not an appropriate response to the challenge of building secure software applications. We can avoid being in tomorrow's headlines by beginning to use the 7 Software Security Touchpoints today.




Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

Post a comment




(Not displayed with comment.)









©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.