Application Security Resources
Sub Text of Application Security Resources
The last few years have been filled with anxiety and recognition that many applications are vulnerable to basic attacks. Now we live in a world where daily reports of massive data loss, denial of service, and even complete ruin of enterprises are upon us. Companies are now realizing that their web applications are houses of straw instead of houses of brick.
The threat landscape is getting worse. Targeted attacks have been designed to steal trade secrets, gather sensitive customer information and destroy critical infrastructure.
Most organizations have already established application security teams and deployed some technology to reduce vulnerabilities. But based on various facts and statistics, the technologies used to minimize issues in web applications are not robust.
This white paper focuses on the strategies that help in building an effective security program for your applications. The paper provides useful guidelines for different stages of your security program. By addressing crucial considerations, offering clear and actionable items as well as real world scenarios, these guidelines could help your enterprise get started and maintain an effective and ongoing application security
strategy. It describes how large companies can discover, catalog and scan web applications to control this major risk vector as part of their overall vulnerability management program.
The strategy for reducing vulnerable web applications is to scan applications, identify insecure code and then fix the code in each application to eliminate vulnerabilities.
Astonishing Facts about Security Breaches
Attacks are normally related to fault injection that could exploit vulnerabilities in syntax and semantics such as SQL injection, cross-site scripting (XSS) and cross-site request forgery (CSRF). The attacks actually insert scripts into requests to alter the workflow and trigger an exploit.
You can use a IAST (InteractiveApplication Security Testing) tool like Seeker, to locate these vulnerabilities. Seeker has the ability to identify vulnerabilities such as SQL injection, XSS and also to update signatures as threats arise. Using a scanner that cannot support the large enterprises with hundreds or thousands of web applications may place your organization in a severely vulnerable position. Many large enterprises do not have a catalog of all their applications.
The other issue is that every web application is different. Some companies may need a PCI DSS report for an auditor and few for targeted penetration testing. These factors may also play a role in determining the right testing tool. Target specifics, automated testing and ease of use are the baselines. Even after considering these details, the job is still only half done.
Application security can’t happen overnight. A successful security program needs to have the right focus and also a realistic time frame. Taking a phased approach that starts small and could be applied gradually across the enterprise is a sensible method.
The technology that supports application development and security plays a vital role, but it can’t solve issues by itself. We need to adopt a strategy with a focused path to ensure success.
The following figure (a rough estimate based on various facts) depicts a five phase approach to achieve success in application security.
Phase 1: Know where you are going
In this phase, you may evaluate applications and identify security vulnerabilities. Before diving in, you must have a firm grasp of the environment. You need not be a security expert on day one, but having an understanding of the nature of security threats can help you.
As different industries have different vulnerabilities, knowing the attacks and common breaches is an important part of your security knowledge.
For instance, in 2011, the financial industry faced a higher percentage of cross-site scripting (XSS) attacks as compared to injection attacks. Identifying attacks that are common to similar enterprises in your industry can definitely give you better ideas.
Compliance requirements may present some security challenges. Regulations such as the Payment Card Industry Data Security Standard (PCI DSS) may require your applications to have additional security measures. They may also affect the security processes. For instance, you may need to produce reports documenting your compliance efforts.
Strategies to adopt
Phase 2: Understanding where you are today
Knowing where you currently stand on application security is another important step.
You need to know the nature of the data exposure your application is allowing. Understanding the types of data such as non-critical information or highly sensitive customer information and also knowing authentication types used to protect it can help you address all vulnerabilities.
Sometimes, external access points pose a bigger threat to companies because they can expose the company to attacks from anywhere on the Internet.
Example: A bank with thousands of applications and various external interface points may face numerous threats from external users who would steal financial data or account information.
Strategies to adopt
Phase 3: Creating a plan
After conducting initial vulnerability assessment and choosing the security areas to target, you can start creating a plan for your security program by identifying a small number of applications to work with. Just focus on applications of highest importance. It is a good idea to start with a limited number of stakeholders.
This approach can help your program begin smoothly. After identifying the applications to prioritize, you may focus on fixing the critical issues. You need to correct the issues and educate the development teams about the vulnerability, including detailed information on the issue and how it can be fixed.
Once you have achieved some initial success, build a repeatable model and apply it to many applications.
Strategies to adopt
Phase 4: Driving operational excellence
Having created a set of processes to address vulnerabilities, you can employ a systematic approach to ensure efficiency. One way to improve your operations is to address the needs of various groups involved that can help you bridge communication gaps.
For instance, development teams are typically designing and building code to meet functional and performance objectives.
In the beginning, they do not have security requirements established, so they do not design, build or test for security. The teams that specialize in security normally play an auditing role in which they review software just before it goes into production, identifying vulnerabilities late in the development cycle. By knowing how various teams are involved and adjusting the processes accordingly, you can ensure operational efficiency in your program.
Addressing the development lifecycle can help uncover cost saving opportunities. By identifying vulnerabilities early in the development as opposed to later in the lifecycle of an application, you can reduce the cost of fixing those vulnerabilities.
As shown in the following figure, the later the defect is found, the more expensive it is to fix. Creating processes that help you discover vulnerabilities earlier can certainly help you add extra defense against security breaches.
Strategies to adopt
Phase 5: Governing responsibly
Governing the application security program is an ongoing activity. It should begin as soon as you have gained an executive sponsor. You may have new perspectives about where your company is today and how far it has come since the program began.
Make sure to keep your sponsor and staff, including management, security, development and quality assurance teams, well informed on your progress.
While you communicate with your teams, make sure that your program stays on track and its processes are consistently followed.
Strategies to adopt
Conducting threat modeling
Threat modeling is the process of evaluating a number of different ways an attacker can harm an application before its development. Here the idea is to proactively determine what sort of security things can go wrong. It is crucial to know these issues at the outset of the development process.
Coming up with abuse cases
Abuse cases (possible attack scenarios) are at the heart of the requirement phase but many companies today overlook this step. Teams are habituated to coming up with a list of functions an application should carry out, but a major aspect of security is indicating what an application should not do. Before compiling a list of abuse cases, companies must think about how an attacker could misuse functionalities. For instance, a customer can look at the bank balance in his account but cannot look at the balance in other’s account.
Test your application
Source code analyzer can scan applications as code is written, looking for vulnerabilities that attackers could use to steal data. Here the idea is to assist developers in writing applications that are more secure, in addition to addressing security concerns in the application development lifecycle.
Dynamic scanners (black box testing tools) attack an application to pinpoint code that could be exploited. Software vendors and open source projects offer these tools that are designed to identify code that is vulnerable to known security vulnerabilities.
Interactive application security tools testing like Seeker, merge the strength of source code analyzer and vulnerability scanner into one unique product. It
analyze code and data flows in runtime to better understand vulnerability context. This approach makes it possible to ties vulnerable code to business impact and exploitation, providing a clear explanation of risks and eliminates false positives.
Test for general resiliency
You need to look at few important things such as:
Sometimes things may go wrong. So make sure the system can recover. Even when an application gets the go-ahead from security experts, keep on testing. New security vulnerabilities come up all the time. Older components of an application may get redeployed as part of a build and this can introduce vulnerable code. Security experts should work closely with operations on a continuous basis.
1. Application Security Training
Developers may assume that all the security comes from the network side such as firewalls, SSL or server patching. Only few people in each company know that web application security lies within the code.
Training must come in stages and it should be reinforced throughout the year. Start out by giving general security awareness training. If the turnover is high or if the development is outsourced, e-learning is a good option. Developers can go through a standard training, demonstrate an understanding of the basics of application security and demonstrate evidence of understanding (for instance, passing a security quiz of some kind).
2. Security Control Libraries
Security controls must be present for certain operations to design your code defensively. You may need a standardized and unified front of security controls. So it is very essential to guide your developers on exactly which security controls they should be using.
Developers should be presented with a set of security controls and they must know how to configure and use those controls in all platforms.
For instance, when developers write SQL queries from within a web application, they must ensure that all user input used in SQL queries has been parameterized. Failure to do this may result in SQL injection.
Note: Do not leave it up to the individual developer how to code defensively. Even among many security experts, there is some disagreement on which security controls have the best balance of performance and security.
Here are some basic areas that need to be covered:
Selecting security controls for your organization may vary according to the language selected and some other factors. So this task could be assigned to internal security professionals.
3. Security Verification during Development
Make sure that developers use security controls in exactly every place where the controls are needed. This is actually what a code review provides i.e. a second set of eyes looking at the code and making sure things are done perfectly.
In the past, internal security teams or security consultants used to review security code. But doing this work manually is normally expensive, non-scalable and time consuming. As a result, many enterprises are now relying on automated tools to easily assess code for the existence of security controls. So, in addition to automated code assessments, manual assessments are also essential.
4. Application Monitoring in Production
So much can still work against us once the application is in production. Sometimes, part of the application workflow might be outside the scope of the source code. We can also imagine an application that may talk to a mainframe, make use of third party web services or internal legacy services that are insecure.
In some cases, issues may arise across other components of the web application.
Vulnerabilities could be found in the platform, the server, stored procedures, libraries and basically everywhere. So, applications in production should receive ongoing assessments to identify and mitigate security threats.
5. C-Level Attention
The path to more secure code has taken us from training, to standard security controls, to code reviews, to dynamic testing (identifying evolving threats).
All these things can only happen with the full support of stakeholders and top management. Teams, scheduling and budgets should all come together to build an internal security program.
Here the good this is, once the internal security program is in place, applications can benefit by having a predictable release cycle. Development team may devote less time to emergency security patches and more time to productive work.
Speed is an integral part of the IT industry and any service that is launched has to be delivered quickly. So, securing web applications is an around-the-clock job. Beginning an application security program can be a significant endeavor, but breaking up the journey into phases can assist you to build upon individual achievements and ensure a great success.
By using all the five phases discussed in this white paper, you can make sure that your security goals and processes are tailored to meet the project needs.
Hence, security is an enabler but not a roadblock.
This post is also available in: Anglais