It's like a broken record – we hear things like "integrate security into the application lifecycle", "security must be built-in up front" and so on, over and over again. Evolved from an era that existed before application security was cool, we've been hearing people evangelize these statements for at least 10 years. But why do we still hear it? Perhaps the better question is: why aren't people integrating security with application...
lifecycle management? In this tip, I'll tell you common reasons security is not integrated; the risks businesses take by not taking security measures seriously and what you can do.
Why don't people integrate security into their application lifecycle?
Everyone has their theories as to why security is having so much trouble being included as a standard part of application lifecycle management. Working with developers, software testers, CIOs and system administrators in small, medium and large businesses across various industries, here's my take on the problem:
- Key people writing and testing software are often excluded from ongoing security and compliance meetings which, over time, can negate the very essence of what the meetings are trying to accomplish in the first place.
- Development and QA are often siloed entities that don't fall within the scope of information security policies, compliance or business risk management.
- Certain development and QA managers who are disconnected from application security often assume that it requires no more than SSL, strong password policies and role-based access controls.
- Developers and QA staff are not encouraged – much less required – to take courses on application security. It's just "not in the budget."
- The very people writing and testing the code are often in the dark on fully understanding the realm of software security flaws, how the bad guys exploit these flaws, and (most importantly) which vulnerabilities are currently present in the system from the bad guys' perspective.
- Many people in development, QA and IT talk the security talk to management, auditors, vendors and so on but there's no real accountability or follow-through.
- There are too many people worried about calculating return on investment (ROI) and hard risk numbers rather than building relationships and demonstrating tangible evidence that security is improving software quality.
- Oftentimes when software developers and testers are required to follow certain security guidelines in the name of "compliance." There's substantial appeal in checking off yet another line item requirement but application security for the sake of compliance only serves to set everyone up for failure.
- Business managers who don't understand application security or software testing have zero empathy for what it takes to do either reasonably well.
All of these issues can lead to a myriad of business risks such as:
- Contract and SLA violations, downstream liability and subsequent lawsuits resulting from flawed applications delivered to customers and business partners
- Security breaches resulting from vulnerabilities present in external and internal business applications
- Compliance violations and audit gaps resulting from the mishandling of personally-identifiable information (PII)
The recent Wellpoint breach exemplifies all three issues. Apparently WellPoint assumed that an outside vendor put the proper security controls back in place for a Web system used for health insurance applications. This assumption led to a five month PII exposure of 470,000 people. Such incidents should serve as a great reminder to management that application security and overall application lifecycle management are a much higher-level business function than they often assume.
What can you do?
So what can you do? Simply do the opposite of what I've listed above. Sure, it can be painfully difficult, if not impossible, to work through some of these issues – especially when there's no incentive on the part of, well, anyone. But if you want to make a difference in your software testing, want to fine-tune your application lifecycle management framework and do what's right once and for all, the least you can do is try. I don't like the word "try" because it often excuses failure in advance, but if you make reasonable efforts to do something about the problem you'll at least have something to fall back on when the security monster eventually rears its ugly head.
The essence of fixing these problems consists of four parts:
- Understand where the risks are
- Get the ear of those in management who can help you
- Come up with a plan
- Show how your efforts are contributing to the business.
If you follow these steps, it's virtually guaranteed you can make a difference.
About the author: Kevin Beaver is an independent information security consultant, speaker and expert witness with Atlanta-based Principle Logic, LLC. He has over 20 years experience in the industry and specializes in performing independent information security assessments revolving around compliance and information risk management. Kevin has authored/co-authored seven books on information security including the ethical hacking books, Hacking for Dummies and Hacking Wireless Networks for Dummies (Wiley). He's also the creator of the Security On Wheels IT security audio books.