Integrating Information Security into the Software-Development Life Cycle
Revised February 2008
Summary: We marvel at the ease with which sensitive information seeps into the hands of those who purport to be the rightful owners, only to discover that we have been not so cleverly tricked. (6 printed pages)
It had been a long day. As usual, there was a constant stream of e-mails, phone calls, and meetings that had consumed my attention that day. I was looking forward to getting home and settling in for the evening, satisfied that I had brought my company value for the day. Then, I got the call. Carol, my manager, spoke very quietly: "Can you come over to my office right away?"
"Sure," I said. "What's up?"
"I'll tell you when you get here," she said weakly.
I picked up my notebook and headed down the hall, apprehensive about the impending discussion. I wondered almost out loud: What does Carol have to tell me? As I walked down the hall, I could hear people in their offices talking in hushed tones. What was going on? I was really concerned. As I rounded the corner, I could see Carol and several other managers huddled around the small table in her office. I could feel the tension the moment that I stepped into the office. "Close the door," Carol said quietly. As I sat down, she said, "Our Web site has been hacked and—as best as we can determine—8,000 credit-card numbers have been accessed."
I remember that day so clearly. I knew that this could happen; I just did not expect that it would happen today. It was routine for applications—especially in our e-commerce department—to be developed quickly, with minimal input from anyone outside of the application team. Ideas usually went from conceptual to code in weeks, with painful episodes of quality-assurance testing and customer reviews that seemed to go on for months. As for security, it was not even an afterthought.
On many occasions, my security team and I had coddled, cajoled, threatened, and downright begged the development teams to include us in the software-development life cycle (SDLC). I am not sure what I was expecting. It was difficult enough for them to follow our company's development methodologies consistently, let alone involve the one group that they expected to slow them down.
We were considered outsiders. Security architecture had not held much meaning for our application or development teams; and, to tell the truth, this concept was new for us, too. We had been traditionalists. Physical security, network security, platform security, antivirus solutions, and audit-logging and monitoring policies and standards were the mainstays of our existence. We had conquered (or so we thought) the intruder problem. Only in the last two years had we begun to realize the risks that were inherent in the software that our company was developing.
This realization had come through the discovery of major changes that were made by our largest desktop-software vendor. Our vendor had sponsored a full week of product reviews for us, and, during this week, they introduced us to their new methodology for secure application development. I was intrigued: a new frontier! Our security team listened intently as our vendor revealed its methodology for integrating information security into the SDLC. Then, the realization hit me: We had a huge gap in our security processes. We would need to get up to speed quickly.
Getting on Track
As luck would have it, our vendor was offering courses in their secure-development methodology. I had not attended any training for that year and thought that this would be the best use of my training allotment. My manager was intrigued, too, and felt that this would be a good investment—not only for my professional development, but also for the company. She was well aware of the challenges that we as a company faced in developing stable software. Now that we had had the opportunity to see how much value a secure-development methodology was bringing in a large development shop, she knew at minimum that we should investigate it.
I went to training. It was an incredibly enlightening week! I soaked up every last little detail about secure-development methodology, and vowed that I would do whatever it took to make this methodology a reality in our company. Infused with excitement and a new sense of purpose, I came to work the next week sure that I could change the world.
I met with my manager to brief her on what I had learned. She listened quietly, absorbing the detail. "There are some major changes that must be made," I said. She smiled and responded with a look that needed no explanation. I knew as well as she did that we had a very hard time just following the development methodology that was supported by the company, let alone infusing it with additional complexities. "We have to try," I said. "Carol, this is serious; application attacks are real. We will only be able to ignore this for a while, before we will be forced to deal with it as an incident."
"You know that budgets and timelines are tight," she responded.
"I know," I said, "but it has been proven that placing attention on the front side of the development process ends up saving time and money at the end of the process."
"I agree with you, but it will be a very tough fight," she smiled. "What do you need to get started?"
I quickly learned that the first thing that had to happen was a leveling of the playing field, so to speak. Architects, developers, engineers, and project managers were the major players on our project teams. It was clear that information security would have to be assigned to a role that would fit well within the project team. One other problem with which we had to contend was that we were such a small team that we would not be able to devote a tremendous amount of time to each project. Still, we were optimistic.
We had to start out small. There were only four people on the security team, and everyone else was already dedicated to security functions that could not be disrupted. I personally would have to take on the challenge of infusing information security into the software-development life cycle. If there was one thing that I knew, it was information security. I had spent the last 10 years as an information-security professional and was well aware of how security was woven into engineering, especially in the design of networks and configuration of platforms. I lobbied to have my title modified to include the "architect" designation. I had minimal experience in architecture, and I knew, to be successful and respected by the other members of the project teams, that I would have to work hard and fast to get up to speed.
Over the next several months, I spent a lot of time learning as much as possible from myriad sources of information for architects—especially, those that were dedicated to security architecture (see the Further Reading section). I had the benefit of relying on several top research firms to help me understand how other companies in our industry were dealing with these matters. Consortiums that were dedicated to companies in our industry proved to be useful, too, as I was able to meet with architects from other companies to learn about their initiatives.
As soon as I had my "architect footing," I began meeting with the various architect groups to understand how they were participating in the SDLC. Unfortunately, I learned that many of them were bypassed during the development life cycle. It was common for the project team to be directed by a development team leader, and for all of the architecture work to be completed without much consideration for the enterprise-architecture models. One thing should be pointed out here, however: Architects weren't left out of the process because no one felt that they were not valuable to the project; they were being left out due to time and cost constraints.
While I had a basic understanding of the steps that I had to take, I did not have experience with the implementation of security architecture within the life cycle. I had not considered how important architecture was to the SDLC, nor had I considered the importance of having an understanding of the overall architectural intent before trying to weave security architecture into the system. To compound matters, I spent many frustrating months begging, pleading, and downright demanding that development teams include security in the project life cycle. When I was finally brought in, I was frustrated by the lack of appropriate architectural information on which to build information-security architecture.
Too Little, Too Late
I continued to push forward, but with little success. Finally, I approached my manager to inform her of the difficulties, which did not surprise her. To effect change, we determined that we would definitely have to bring these issues to the attention of the company's senior IT leadership team. But, before we could get our bearings, we learned of the breach. As the reality and gravity of the situation sank in, I realized, as hard as we had tried, that we had failed. We had not failed due to effort or desire to make our applications more secure; instead, failure had resulted from lack in the following areas:
· An understanding of technology architecture
· Sufficient integration of information security into the development life cycle
· An understanding of the complete technology-architectural picture
It became clear that the importance of having good security processes to weave into the development life cycle—as well as the support and participation of architects from all technology disciplines working together—is imperative. Most of all, gaining the support of the project team to integrate the security-architecture methodologies into the development life cycle ensures success.
While this story as a whole is fictitious, I have experienced many elements of this story in various positions that I have held. The presented situation has happened—and will continue to happen frequently—until information security is fully integrated into the development life cycle and collaboration with other architecture disciplines consistently.
Security architecture is no different from other technology-architecture disciplines. Security architects must have a solid understanding of application, platform, and communication architecture to be able to apply security architecture in an appropriate way. This means learning as much as possible about technology, and developing good working relationships with the other architects in your company. Developing strong partnerships with other architectural groups will greatly enhance your chances of success, when you are developing security solutions for the project.
The security architect also must have consistent processes that will integrate well into the development life cycle, to ensure that security is addressed at each phase. Typically, the security architect should expect to perform the following steps to a greater or lesser degree, depending on the solution that is under development.
At this point in the life cycle, the security architect should gain a solid understanding of the conceptual design. User populations, classes of data, and technologies might not be well known yet. You will, however, certainly be able to determine such issues as whether the application will offer Web services, whether it will be internally or externally facing, and which line of business will own the application. At this point, you should be able to advise the project team on which security issues they might face, as they more finely tune the conceptual architecture.
Security requirements—As soon as all business requirements have been gathered and the technology requirements are well under way, the security architect can begin to define security requirements. Looking at the functionality that is required by the business and the technology that is being considered for the project will provide the road map for the security requirements. It is important to consider the following information, when you are developing security requirements:
The user base—Are users internal, internal and external, or all external? What roles are needed? What will the identity-management solution be?
Data classification—To which data will users have access? What special protection mechanisms are required, based on company policy and any applicable regulations?
Technology—What technological solutions are being proposed? Does the solution include Web services, client/server architecture, platforms, and communication technology that do not currently exist within the IT environment?
Existing and emerging security threats—What threats exist currently for the company, and what threats are emerging in the industry? Understanding the current threats will enable the security architect to understand the level of risk to which the company will be subject, given the introduction of the new technology solution.
Design—As soon as the security requirements have been solidified, the architect will have to ensure that the final design incorporates the security requirements. The security architect should sign-off on the design, attesting that the security requirements have indeed been included in the final design.
Testing—This is one of the most important aspects of the life cycle. If the security architect has executed the preceding steps properly, this step should be relatively simple. The architect must ensure that the testing team includes test cases, to vet the security controls that are incorporated into the solution. These controls should relate directly to the security requirements and how those requirements were translated into the design.
Implementation—While there is not much for the security architect to do in this step, it is imperative that the security-control test results be carefully reviewed and approved by the security architect, prior to the solution being approved for production. If the test results prove that the security controls are functioning as intended, the role of the security architect in the development/project life cycle is complete.
· Howard, Michael, and David LeBlanc. Writing Secure Code: Practical Strategies and Proven Techniques for Building Secure Applications in a Networked World. CD-ROM Edition. Redmond, WA: Microsoft Press, 2001.
· Howard, Michael, David LeBlanc, and John Viega. 19 Deadly Sins of Software Security (Security One-Off): Programming Flaws and How to Fix Them. New York; London: McGraw-Hill/Osborne Media, 2005.
· Viega, John, and Gary McGraw. Building Secure Software: How to Avoid Security Problems the Right Way. Boston: Addison-Wesley Professional, 2001.
About the author
Kelley Holland has been an information-security professional for over 15 years. She has experience in a variety of industries, in addition to experience with development of information-risk programs and methodologies.
This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.