Application Security Resources

Sub Text of Application Security Resources

How to accomplish Application Security in Business Processes?

January 1, 2014

Tiny Url for this post:

Introduction and Background Information

Many web based applications have common security vulnerabilities such as cross-site scripting and SQL injection attacks. Even the platforms they run on are more vulnerable when compared to their ancestors like mainframes. As a result, these applications expose enterprises to a substantial amount of security related risks.

Web development teams have not traditionally been focused on security. Their incentives and their priorities have been primarily tied to meeting deadlines or implementing new features. Many development teams don’t realize that their actions can affect security. They actually view security as a job to be handled by others and not by developers.

Hackers have already learnt that many web applications could be exploited via the mistakes made by the developers while building those applications. By just making use of common vulnerabilities, a hacker can make the software misbehave in many ways and this includes granting access to unauthorized information.

But the changing threat landscape has forced security focused companies to address application security through secure software development. Here is a simple truth: Security measures that are “bolted on” after the completion of software development process are not that powerful in countering web application attacks.

This white paper is aimed at program and project managers, developers, and all individuals supporting improved security. It is also relevant to all the members of software engineering processes who wish to integrate security into their standard development process.

The Issue

A process is defined as a sequence of steps performed for a given purpose. A business process is a set of actions facilitating the transaction of business with an internal or any other external entity.

Companies that value time-to-market over security tend to automate their business processes using web enabled applications. In most cases, these enterprises do not establish adequate auditing functions and strong security controls needed to alleviate all risks that can result in serious financial damage.

A major issue is that most security professionals do not come from a strong development background, and that is especially from modern web application development platform backgrounds.

Vulnerability Management Procedure

Many applications have not been adequately tested for security vulnerabilities. Normally a process based and a proactive approach is highly effective.

An overall business process protection includes a well defined inventory system for critical business processes and attentive monitoring programs to detect abnormal activities.

Few procedures for application vulnerability management include:

  • Identifying vulnerabilities of systems assisting critical business processes.
  • Testing in a non production environment and removing disastrous changes.
  • Patch distribution with reasonable operational costs.
  • Proposing temporary countermeasures when patching can’t occur on a regular basis.
  • Planning for failure modes and to make sure that damage is reduced if something goes wrong.
  • Appropriate change controls and management.
  • Proactive measures like developer awareness.
  • Compliance with regulatory requirements.

All these procedures should be placed within a unifying framework, in this case it is known as development lifecycle. Security checks must be included, and ideally as gateways to successive phases. Logging and auditing functions should be incorporated into the development process earlier so that automated tools or applications can meet all the requirements of an enterprise. Here is the procedure:

secure development lifecycle

Vulnerability identification

Vulnerability identification is usually overlooked as a source of risk. Broken access controls, unverified parameters and buffer overflows are few types of the major potential security vulnerabilities found in complex applications. So they need a vigilant patching process. It is also considered that a web application is as secure as the platform on which it runs. Documenting secure builds for all operating platforms should be done on an enterprise level.

Systems and production servers must be scanned using the latest signatures frequently to ensure their immunity from system level vulnerabilities.

Separating development and quality assurance environments

Quality assurance (QA) and development platforms must be separated from the production network. Before promoting an application to production environment, it should be tested for vulnerabilities. This is generally considered as the last step in the development lifecycle and must be repeated when an application is reconfigured, patched or upgraded on the operating system.

Patch distribution

Operating systems and applications developed by other enterprises should be monitored regularly for the latest security patches. Developers must also examine the application code created internally and release patches or new versions as required. But maintaining this degree of vigilance is normally difficult for large enterprises with complex environments and high uptime requirements.

The central principle for the success of a patch distribution process is whether it could be applied before an exploit is posted on the Internet. Before applying the patches, they must be tested thoroughly in the QA environment.

Temporary countermeasures

Agile enterprises can implement temporary countermeasures. This actually means following a defined incident response plan and shutting down ports on firewalls and routers or blocking certain IP addresses. The ability to put together an incident response team, notify all necessary parties and following well defined guidelines for issue escalation process is very essential to implement these countermeasures strongly.

Failure modes

A failed application will most probably have a negative impact on a business process. Enterprises must build in multiple checks during the development process to aggressively avoid failures. As we are aware, the possibility of a failure can’t be eliminated completely. To manage the risk efficiently, enterprises must devote a step in the application maintenance process to realize failure modes and also various difficulties encountered once in production.

When an application fails, the company must have provisions in place for the overall process of the business. But an application should never fail open.

“Fail open” refers to an instance when, upon failure, all sorts of transactions are permitted through the system. So an application or its internal checks must always fail close.

Change control and management

Many businesses have developed many methods of transferring financial data to and from their business partners. This data may include contractor invoice submissions, profit and loss projections and other sources that are of questionable integrity because of the way they are transmitted.

There is no guarantee that the data is unmodified or has not been removed between the time it was sent and received. The lack of a secure transfer may restrict cyber forensics if thorough change control and management processes are not precisely followed and not documented.

Additional measures – Policy and developer awareness

It is important to educate developers about the techniques and tools required to write secure code as well as the importance of the project. Secure code policies should be kept high-level enough to meet the needs of the full breadth of enterprise projects.

A programmer who is providing code that may impact business processes should possess a basic knowledge of the topic. This is depicted in the following figure:

Security measures


Note: Sometimes developers may disagree about the best method to achieve security. Flexible guidelines must be developed for more specific guidance and peer review is also a useful part of the development lifecycle.

Strategy for Secure Development


A secure process is a set of activities performed to develop and deliver a secure software solution. A process model provides a reference set of best practices that can be used for both the improvement and assessment of a process.

Almost all enterprises conform to a specific process model. But there is no guarantee that the software they build is safe from security vulnerabilities. In order to build secure software, enterprises must follow solid software engineering practices, risk management and appropriate use of tools.

Let’s discuss about the secure development strategy or plan. The tasks included in this plan are identifying risks, defining security requirement, secure design, code reviews, use of static analysis tools, unit tests and fuzz testing. Fuzz testing actually involves giving random inputs to external program interfaces at the time of black box testing.

Each member of the team has to select at least one role (sometimes roles can be shared). One of the defined roles is a security manager role. The security manager leads the team in making sure that the requirements, design, implementation and testing can address all security related issues. By doing this, you can ensure that the application is statically and dynamically assured. It also provides timely analysis and warnings on security problems. The security manager has to work with external security experts as and when required.

Here the strategy is to have a number of defect removal points in the development life cycle. If there are more points then you are more likely to find issues right after they are introduced. This helps in fixing the issues easily and to determine the root cause effortlessly.

We can just consider each defect removal activity as a Filter, which eliminates certain defects that can lead to vulnerabilities. This is depicted as below:

Filtering vulnerabilities


If there are more defect removal filters in development life cycle, fewer defects will remain in the application when it is released. Early measurement of defects enables you to take early decision and action in the development life cycle.

Each time defects are removed, they are once again measured. So each defect removal point could become a measurement point. This sort of defect measurement tells teams where they stand against their goals. It helps them decide whether to stop and take the necessary action or move to the next step. It also denotes where to fix the process to meet appropriate goals.

It is advised to consider these five queries while managing defects:

  • Where defects should be measured?
  • What sort of defects lead to security vulnerabilities?
  • How many defects can be eliminated at each step?
  • How many defects remain after each step?
  • What methods and tools must be used to measure these defects?

In this security strategy, we can include training for managers, developers, and other team members as well.

Best Practices

Here are the 8 best web and mobile application security best practices. These are very essential but they need not be in any specific order.

1. Know your apps

In some cases, enterprises don’t know how many web and mobile applications they have and where all those exist. Maintaining an inventory of the applications is very crucial in such situations – You would be surprised by how many rogue applications are out there. Many solutions are available that can locate all your existing applications.

2. Busting those myths

Busting few myths around application security is vital. For instance, SSL doesn’t protect you from attackers exploiting web vulnerabilities. If you understand this, you need to be aware of the buzz word vendors. Even though their solutions are aimed at completely different set of problems, some vendors claim that they can detect security vulnerabilities.

3. Prioritizing your apps

As you are aware, not all apps are created equal. After identifying your apps, you must categorize them as Critical (i.e. external facing with client information), Serious (external or internal that consists of certain sensitive information) and Normal (less exposure). You still need to have a plan to test them all but categorization could help you to test them at optimal levels. For instance, you can test the most critical applications with a complete robust suite of attacks, serious applications with common attacks, and the normal ones with basic tests.

4. Quantitative scoring

If you have sufficient budget and you start testing all your applications, you may notice that almost every application will have hundreds of vulnerabilities. This is actually overwhelming and demoralizing. But if you can prioritize these vulnerabilities based on some sort of quantitative scoring, the task could be managed easily.

5. Don’t forget production applications

It is a common practice to focus only on apps that are going through development lifecycle with new code and some changes to an existing application. It is essential to test those. But many of your applications are in production and could be seriously vulnerable. So you are not supposed to wait for the next set of changes to test for vulnerabilities.

6. Celebrate

You have to celebrate your small wins. Celebrate after each application you secure with no major vulnerabilities. For passing a compliance audit or for doing better than other business units, just celebrate.

7. Security tools and training

Security professionals must understand the tools used by the development team in order to integrate security into their work flow effectively. Security tools are vital components of any software assurance program. Security professionals should try to support development teams by knowing how developers use their tools while looking for methods to enhance and tune those tool sets.

8. Ongoing collaboration

Security professionals must use the results from testing activities as an opportunity to sit down with development team leads, discuss the findings and begin the process of identifying web application software defects by using vulnerability data from the reports. This collaborative approach can provide better opportunities for security teams to work with development teams and address flaws in production Web applications. They can also improve the security of future application deployments.


Secure software doesn’t happen overnight. Security teams can ensure a harmonious and team focused effort by just taking a long term view of the process. This approach can eventually result in developing applications with very fewer flaws.

People generally have good intentions but the task of web application security can seem daunting and make them to delay patch initiatives. Hence by positioning security as a business enabler, regulatory requirement and liability limiter, we can take all the necessary measures in safeguarding web applications and also business processes they support.





This post is also available in: Anglais

Learn more about Seeker

More Base de connaissance