Introducing Security into Mainstream Development – Part 1

We held a webcast last week with Mark Wireman of OpenSky, who is an expert in application security and has worked in this space for 15 years. We appreciate Mark taking the time to share his experience securing applications in the enterprise and responding to the onslaught of mobile-based entry points in the application development process.
During the course of the hour, we received a number of interesting questions and comments and thought they would make great topics for a few blog posts. Stay tuned for a follow-up post from Mark, which will include answers to several questions on Appsec in agile development.
Defensive vs. Offensive
There was a question during the webinar about defensive and offensive strategy as they relate to security. Mark will elaborate on them in his post, but we wanted to say a few words about them as well.
At CAST, we see many companies taking a code quality approach to application security. That is, they look at software analysis at the code level and use that to flag potential security issues — typically after the SDLC dumps the code into production. While that might seem like a reasonable approach, we believe it’s not enough.
Virtually all thought leaders in application security believe the most advanced security measures are realized in architectural analysis of applications. Truly good security should include elements of an architecture that protects application data, and a process that guarantees security aspects of the architecture are not bypassed. We’ve only seen that deployed by a few CAST customers, and nowhere else. But we believe we’ll all get there, eventually.
Many Layers
Towards the end of our session, we received this comment:

It’s also only a start to mobile security…there are many other layers that need to be considered but yes it was a well spent hour

We wholeheartedly agree. Mobile apps only raise the stakes and the importance of securing sensitive data. As we heard from Mark during the webinar, and we hear from the assurance community, most attacks are trying to find their way to the data. We believe that it’s much more than the mobile app that needs to be secured — it’s a system-wide problem that involves the whole application. It’s an issue of overall architecture and how the entire system needs to be designed with security in mind. The mobile app is just one piece, but an important entry point into the legacy application and hence, part of the overall system architecture.
Stay tuned for more details and answers from Mark in part two of this post.

Raymond James’ Aha! Moment with Integrating Software Quality

When my organization decided to hire a new CTO, one of his top priorities was to look through our old support contracts and “cut the fat,” as it were. It was there, among the rubble, where we found a transformational tool that we had cast aside which could help us increase our development productivity and software quality. But in learning more about this tool we found that it hadn’t failed us, but rather, we failed it!
So my brand-new boss gave me a brand-new ultimatum: Integrate this tool into our software development lifecycle, or we’re dumping it.
The tool was CAST’s Application Intelligence Platform (AIP), used to increase an application’s structural quality during development. Previous teams had struggled with this tool because they thought of it as a plug-and-play solution that would fix all their problems, instead of an integral part of the development lifecycle. And when it didn’t work, all too often it was the tool itself that would get blamed. We knew we had to figure out a way to alter development’s perception of software quality in order to get this project off the shelf.
We started scanning applications with CAST, and immediately hit a roadblock. The reports were coming back with a lot of violations and many developers started to panic thinking, “the sky is falling!” We had to take a step back and explain that tackling every violation would be costly and ineffective — only critical violations were going to swing the quality needle. After those violations were fixed and rescanned, their quality scores improved by 30 percent … this would be our Aha! moment.
But even with the improved scores, we found our quality processes were still not being integrated into the development lifecycle. So we decided to stop making it optional. We asked senior management for a list of our most critical business applications, and we started approaching teams like police with a search warrant. With a swift knock on their door we could say, “Your application has been deemed critical by our senior leadership, and we’re here to check the code.”
With this approach, we got no objections at all. Teams made time because they understood that their app was critical, and we needed to capture specific quality metrics, such as complexity and transferability, as well as how well our development team coded to not only our own standards, but those of the rest of the industry. What’s more, after their application had been analyzed once, they could never release new code that was lower quality than the previous version. This made it very easy to implement a quality gate; one that was objective instead of anecdotal, and is supported by new violations popping up in the code.
We learned a lot in our first year — we scanned 12 applications as we refined our process even more. And development teams began to see how these scans could help them produce more efficient apps. Today, we’ve been able to make significant progress in our entire application portfolio, having increased the footprint of scans to 58 apps. In just over a year’s time, CAST had become an integral part of our software development lifecycle.
Looking forward, our next steps are to automate the process as part of a continuous delivery effort to increase deployment speed. We also plan to partner with software engineering managers to objectively determine who our best coders are across the board, and who we need to focus coaching on.
Lots of companies like to talk about software quality, but there aren’t many that live it, breathe it, and love it. But if you really want to get software quality assurance working in your organization, it needs to be institutionalized into your entire development process. That’s the power of the CAST AIP — the more we worked with it, the more difficult it’s been to develop quality software without it.