eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Developers have long struggled with the security conundrum of how to quickly deliver apps that are as inherently secure as they are robust, reliable and efficient.
In today’s fast-paced world of mobile, social, cloud and often complex enterprise applications, pressure is on developers to produce applications faster than ever. Yet, despite that pressure to deliver more apps faster, there is just as much pressure—brought on by those same mobile, social and cloud factors—to deliver applications that are more secure and reliable than ever before. What’s a developer to do?
“Time-to-market pressure results in continually shrinking software delivery windows, while the business risks associated with software defects have never been greater,” said Jennifer Johnson, chief marketing officer for Coverity, the maker of the Coverity Development Testing Platform, an integrated suite of software testing technologies for identifying and remediating quality and security issues during development. Coverity’s platform automatically tests source code for software defects that could lead to product crashes, unexpected behavior, security breaches or even catastrophic failure.
According to IBM, application security vulnerabilities can be introduced in various phases of the development cycle. The requirements and design process fails to consider proper security; flaws are introduced inadvertently or purposely introduced into the code during the software implementation, or during deployment because a configuration setting did not match the requirements of the product within the computing environment—for example, when unencrypted communication is allowed over the Internet.
To limit such occurrences, IBM has instituted a structured development process for delivering secure applications called the Secure Engineering Framework, which recommends the use of automated security analysis tools and proven certified security components.
These tools include source code security analyzers, bytecode security analyzers, binary security analyzers, dynamic analysis tools and runtime analysis tools. Source code analyzers analyze application source code to locate vulnerabilities and poor coding practices. These tools can also trace user input through the application (code flow analysis, taint propagation) to uncover various injection-based attacks. Bytecode analyzers analyze application byte code (relevant for certain languages only) for the same vulnerabilities as source code analyzers. Binary analysis is very similar to source code analysis. However, instead of evaluating the source code, this analysis examines the application binary.
Dynamic analysis tools perform analysis of the application as a black box, without knowing its internal operation and source code. Dynamic analysis tools automatically map the application, its entry points and exit points, and attempt to inject input that will either break the application or subvert its logic.
Runtime analysis is not a specific security analysis technique or tool. It is the software development practice targeted at understanding software behavior during runtime—including system monitoring, memory profiling, performance profiling, thread debugging and code coverage analysis.
All these types of tools play a part in what Caleb Barlow, director of mobile security at IBM, likes to call security by design.
“The whole idea is to recognize that if you think about security in the design of your applications in the very beginning, and if you use security tools during the build process and during the development process, at the end of the day you’ll actually save money—in addition to having a better protected application,” Barlow said.
“The reason is fixing a security vulnerability early in the development lifecycle is very inexpensive. Let’s say you find a bug and maybe it takes a half hour of a U.S. developer’s time. What’s that cost you, maybe $50 or $100. But if you find a bug late in the development cycle, you then have to go figure out where it was in the code, then you have to remediate it, then you have to retest, you have to rebuild, you have to repackage and maybe do multiple testing scenarios.
Secure by Design: Developing Apps Without Flaws Takes the Right Tools
“All of a sudden that same vulnerability may cost you many thousands of dollars to remediate,” Barlow said. “And, of course, the worst case is when you release the software product with vulnerabilities or security problems in it, and now the dollar figures could be in the millions. In our scenario and I think in the scenario of a lot of large software providers, if we have to go out and issue a patch for a security vulnerability, that’s a number that’s easily measured into the millions of dollars. Because we have to redistribute the code.”
Barlow said IBM stresses the use of scanning tools. IBM has its Rational suite as well as AppScan and other security tools in the Worklight suite for mobile development. Big Blue wants its developers scanning early and often, he said.
“The analogy I like to think of is the days before spell check,” Barlow said. “With spell check you become a better speller because when you spell a word wrong enough times you’ll realize your mistake. Well, the same is true in developing code. If you are poorly writing your code and using poor syntax, you can inject vulnerabilities into that code fairly easily. But if you’re catching that as you’re doing it, you’ll learn. So a big part of our tool in this space is as much about scanning for the vulnerabilities as it is about providing education for the developer on how best to write their code.”
Barlow said a typical scenario is to do source code scanning during the build process and once you’ve got a working prototype of your application you switch from source code scanning to dynamic scanning, where the developer is acting as a penetration tester or hacker.
IBM provides these tools that run on most common languages and also features support for iOS and Android. Barlow said IBM dusted off its AppScan tool and added support for 40,000 mobile APIs—between iOS and Android.
For its part, Microsoft has its own version of what IBM calls its Secure Engineering Framework, except Microsoft’s is called the Security Development Lifecycle (SDL). The SDL came into being after Microsoft software came under incessant attack in the early 2000s, Glenn Pittaway, senior director of strategy, architecture and policy for Microsoft Trustworthy Computing, told eWEEK. At the time, malicious attacks on Microsoft by nefarious code such as the Code Red and Nimda worms prompted Bill Gates to write his famous “Trustworthy Computing” memo.
“Trustworthy Computing is computing that is as available, reliable and secure as electricity, water services and telephony,” Gates said in the memo. “Security models should be easy for developers to understand and build into their applications.”
The Microsoft Security Development Lifecycle is a software development process used and proposed by Microsoft to reduce software maintenance costs and increase reliability of software by preventing and eliminating security-related bugs. Microsoft’s SDL emerged out of that Trustworthy Computing thrust, and by 2004 SDL became a mandatory policy inside Microsoft. All products that address an enterprise audience or touch the Internet need to go through SDL processes, Pittaway said.
“So you can say that every single product is subject to the SDL,” he said. “The way we’ve implemented this mandatory policy is we’ve produced—in conformance to ISO terminology—policy standards and procedures behind kinds of behavior we want to enforce or prevent. For instance, we want to prevent buffer overruns and we want to enforce the use of good crypto technology.”
Microsoft did have to take notice of new processes and techniques such as Agile development. “A few years ago we were getting feedback that the waterfall style of SDL was not reflective of the way many groups inside Microsoft developed products,” Pittaway said.
Secure by Design: Developing Apps Without Flaws Takes the Right Tools
“So we adapted the SDL so that groups using Agile could use the SDL. And we’re constantly looking at things like that. Now the move is toward continuous release,” said Pittaway, where the company releases updated product versions six times a day or more. In such a situation, he asked, “How do you make something like the SDL relevant in that kind of context?”
Indeed, John Dickson, a principal at the Denim Group, a software security consultancy, made the same observation.
“Microsoft’s SDL is probably the most famous,” Dickson said. “I think these security frameworks are a great starting point. What I see most frequently is people taking those and adapting them for their environment.
“Most companies have not one software team and not one software technology, so what we see is people have .NET and Microsoft but also J2EE and Extreme Programming or some type of Scrum, also Web and mobile,” Dickson observed. “How do you adapt that to a different framework? That’s where the good guys are separating themselves out from everybody else.”
When Microsoft started the SDL it had no tools, though users began asking for tools support. “When you are effectively the platform for the planet, you have the obligation to make sure that the products you are selling are safe to use,” Pittaway said. “So very early on we also started to externalize the SDL and its guidance and policies. But we very quickly got back that people wanted tools. So we started to release tools to third parties, and you can download them from Microsoft.com/sdl.”
One of the most popular tools is for threat modeling, which is a very key part of the SDL. Microsoft also offers BinScope, which is a binary analyzer, and MiniFuzz, which is a basic testing tool designed to help detect code flaws.
In addition, Microsoft offers the Attack Surface Analyzer as well as a Team Foundation Services template so users can apply the SDL on their project as they manage it. Another tool is banned.h, a code sanitization tool in the form of a header file designed to locate potentially insecure APIs (also known as “banned APIs”).
In Visual Studio 2013 there is a /SDL flag that “switches on all the more useful protections,” Pittaway said. Microsoft also provides static analysis tools like PreFast and PreFix. There have been more than a million downloads of the SDL tools.
Mark Troester, director of product marketing at Sonatype, which provides component life cycle management solutions, said developers must “think about the entire software lifecycle. As they should, developers will do what they can to deliver apps fast. It’s up to the architects, dev management, security team, QA, etc., to be involved and ensure that security is considered throughout the entire lifecycle. But these supporting roles must support security, licensing and quality controls in a way that doesn’t hinder developers.”
In a study of 150 development shops, Forrester noted that those using Microsoft SDL saw better return on investment (ROI). “It turns out that those practicing SDL specifically reported visibly better ROI results than the overall population,” the Forrester study said. “Unlike point technologies, SDL advocates a coordinated approach to application security throughout the life cycle and its emphasis is on a set of processes that supports such coordination.”
After a series of SQL injection attacks from the Internet exposed weaknesses in its IT systems, MidAmerican Energy Holdings used the SDL as the backbone for a security effort the company put in place.
The SDL “is a way for Microsoft to improve the security of its code and a way to help people writing software for its platform,” said Jeff Williams, CEO of Aspect Security, a Columbia, Md.-based security firm that provided security training services to MidAmerican.
Meanwhile, MidAmerican looked for scanning tools and selected Fortify 360 from Hewlett-Packard’s Fortify division. It also decided to follow Open Web Application Security Project (OWASP) standards.
Secure by Design: Developing Apps Without Flaws Takes the Right Tools
So by merging OWASP standards with the SDL and scanning tools from Fortify, MidAmerican girded itself for battle and set out to deliver secure applications.
“Organizations often lose time and money by failing to incorporate security processes into the early stages of application development,” said Mike Armistead, vice president and general manager of enterprise security products at HP Fortify.
Itron, which builds solutions that help utilities manage energy and water, also became an SDL user after facing security threats. “I got tired of writing six-figure checks to these outside vendors,” said Michael Garrison Stuber, an Itron engineering adviser who manages the security for the company’s product line. “From a business standpoint, it just made perfect sense to me that we need to be investing in how we do development so we’re thinking about security throughout the life cycle.”
Secure at the source is a mantra for companies like Denim Group. “Our goal, our mantra is to build a world where software is more trusted,” Dickson said. And that means building security into the process.
Dickson suggests that development shops implement a handful of upfront activities before they even go to the design phase. One is to expose developers to basic security concepts. Another is to come up with a very simple, but standardized way of doing the most important things and articulate that on a 3×5 card or in a top 10 list.
That list should include things like “we always protect client data at rest.” Another requirement could be that “we always protect customer data in transit,” which means you use transport layer security.
“What we found is if an organization can succinctly define that up front, they save so many conflicts and heartaches further down the line,” Dickson said. “If you don’t define, for example, how you handle logins, you may have all the development teams implement what they think is the right way, and with all those different iterations you’re going to have a handful that is just totally wide open.
“And we’re not talking about malware here. We’re talking about good developers who are well meaning, but through lack of knowledge or whatever they introduce vulnerabilities inadvertently into software that then subsequently get exploited by attackers to do bad things. And when they do that it’s usually because the standards are not particularly defined,” Dickson said. He also encourages setting standards for session management.
“The next thing we do is threat modeling,” he said. “We recommend this to be at the highest level. You map out how the application works with two or three things in mind: Where data ingresses the system, where it egresses, and then how data is stored and what are the areas of trust in the application.”
An Aberdeen Group study identifies three types of approaches to providing application security: secure at the source, defend and defer, and find and fix. Aberdeen also surveyed 150 shops and found that the average respondent invested nearly $400,000 annually on application security issues. However, the cost of remediating an application security-related incident is about $300,000.
The good news is that companies adopting the secure-at-the-source strategy realized a very strong four times return on their annual investments in application security, the Aberdeen report said.
Mendix, which offers a codeless development environment, claims the very nature of its software approach eliminates security issues. Mendix uses a visual Model-Driven Development approach without the need for traditional programming and code that lets developers build applications quickly and easily integrate them with existing enterprise systems.
It features one-click deployment so users can instantly deploy their applications in the cloud or on-site. The platform also provides centralized IT control, governance and security, said Johan den Haan, CTO of Mendix.
Secure by Design: Developing Apps Without Flaws Takes the Right Tools
“The way we approach application development ensures that we have a much better approach to security,” den Haan told eWEEK. “There are three main things in our platform that change the game in app security. While we interpret all these business models as working applications, we have a single engine that’s used with all our customers. And that engine contains all the necessary security mechanisms.
“They’re all available out of the box—things like authentication APIs and role-based access are all part of the toolset, and you don’t have to think about it,” he said.
“The second thing is while we have all these high-level models we can do all kinds of static analysis on these models. And third we have one central, battle-hardened cloud platform that’s been tested and certified. And our customers do penetration testing on the resulting apps, and everything we’ve learned from that over the years we’ve directly fed back into our engine,” den Haan said.
As noted earlier, HP Fortify offers scanning protection for customers. HP Fortify helps users reduce their security risk by offering both on-premises and software-as-a-service (SaaS)-based solutions to identify, prioritize and remediate application vulnerabilities. The solutions also enable organizations to save time and resources by eliminating risks in the early stages of the application development process, when they are easier and less expensive to fix.
Spain’s Novagalicia Banco uses HP Fortify on Demand to run ad-hoc analyses on the source code of approximately 400 applications, including areas such as mobile banking, e-banking, payment gateways, corporate Websites and wire transfers.
“We were in search of a security solution that was capable of analyzing a large amount of code, with minimal adaptation, and worked across many programming languages,” said Roberto Baratta, chief information security officer at Novagalicia Banco.
SAP’s development process includes using Coverity’s tools to help implement security early in the development process. “Coverity enables developers to produce secure code and gives developers a more positive attitude about addressing security, which ultimately leads to fixing security issues early and protecting SAP’s and our customer’s brands,” said Uwe Sodan, Security Code Analysis Team Lead at SAP, in a blog post.
But how much application security is enough?
“It depends on the threat,” said Denim Group’s Dickson. “If you are a non-profit, you’re going to do a certain level of testing because the threat is pretty low. But if you’re Bank of America and you know that the Russian and Eastern European hacker gangs are going to go after every piece of your software, you have to do much more rigorous testing,” he said.
“If you go to the big banks, investment houses and insurance companies, they do rigorous testing because they know the threat is off the charts. They know the fraudsters and the Eastern European attackers are going to try to manipulate their software.”
Overall, the essential principles for designing and writing secure systems are well-studied and mostly boil down to good software development practices, said Al Hilwa, an analyst with IDC. However, the problem is that it is time-consuming and requires a great deal of discipline to stick to them.
“For example, by design systems should strive for reduced complexity and thus reduced surface area for attacks; user input should be validated carefully; features should be locked down by default; the system should require the least privilege possible to operate, etc.…,” Hilwa said.
“There are design-time, code-time and, of course, the all-important test-time practices that have to be employed to improve the level of security,” he said. “Fundamentally, the fewer the bugs in a system, the more secure it likely is.”