Most software and test professionals believe security must be addressed after, not at the time of app development process, according to industry professionals. While software developers and test professionals are known with application testing and security thought, most work for companies that lack all-inclusive app security techniques.
Software Testing experts asked application security professionals to recognize and address security concerns at each stage of the app lifecycle and to propose tools and method to aid security. Here is the advice they offered.
1. Conduct threat modeling at the outset on an app development project. Threat modeling mention to the procedure of figuring out how many different methods an attacker could harm an application before that application is actually developed, said Wendy Nather, research director for the enterprise security practice at 451 Research LLC, a research firm based in New York. "Can you break into it, commit fraud, steal from it? That is what you are trying to answer," she said.
The best threat models graphically depict things such as how data will flow and how it will be stored, said Dan Cornell, a principal at security consultancy Denim Group Ltd. in San Antonio. "The idea is to proactively determine what kinds of security things can go wrong." It's crucial to understand these issues at the outset of the development process because it's cheaper to address security concerns when an app is "just a drawing on a whiteboard," he said.
2. Define basic requirements that address security. Developers today -- even those without specialized security testing training -- do a decent job of dealing with the rudimentary aspects of application security: role management, authentication, password-based access control. But there are still things to watch out for, Beaver said.
3. Come up with abuse cases. Abuse cases, or possible attack scenarios, are at the heart of the requirements phase, and yet many companies today overlook this step. "Teams are accustomed to coming up with a list of functions an app should carry out, but a key aspect of security is specifying what an app should not do," Cornell said. To compile a list of abuse cases, he advised companies to think about how an attacker could misuse functionality.
4. Define rules for input validation. Nather views this process as figuring out the trust zones in your application. "What you want to know is which parts of the system trust each other, and should they trust each other?" Once you figure that out, you can define rules such as the following:
Don't trust data that is coming in from the Internet.
If you pass data inward to a second tier of architecture -- from the Web server to a database, for example -- check the data before accepting it.
Validate all data moving in both directions, in and out of the application.
4. Use source code analyzers. Source code analyzers scan apps as code is written, looking for vulnerabilities that an attacker could exploit to steal data. The idea behind them is to help developers write apps that are inherently more secure at the outset, in addition to addressing security concerns later in the application lifecycle.
5. Guide developers to write secure code. Another way to boost application security testing at the coding stage is to provide pre-existing libraries that implement common tasks in a secure fashion, Cornell said. Essentially, you are supplying code templates that model "here's how we do database access; here's how we build webpages that avoid cross-site scripting errors," he said, referring to a well-known vulnerability attackers use to steal data.
7. Use dynamic scanners to simulate attacks during the QA cycle. Also known as black box testing tools, dynamic scanners "attack" an application in much the same way a hacker would, in order to pinpoint code that could be exploited. Commercial software vendors, as well as open source projects, offer these tools, which are designed to identify code that is vulnerable to SQL injections and other known security vulnerabilities, Cornell said.
8. Test the application against the deployment environment. The test environment should mirror the environment in which the app will be deployed as closely as possible, Nather said. A key thing to look at here is whether access to data sources is secure.
9. Test for general resiliency. Can the app recover easily when the connection is disrupted? Or when part of your cloud goes down? Or a batch job fails? These are things you need to look at, Nather said. "Things will go wrong, so make sure the system can recover."
10. Retest apps in production on a regular basis. Even when an app gets the go-ahead from security experts, keep on testing, Nather said. "New security vulnerabilities come up all the time." In addition, older components of an application can get redeployed as part of a build, potentially introducing vulnerable code, she said.
No comments:
Post a Comment