Security Policy Template for Web Applications

Web applications are critical to the enterprise infrastructure. Companies rely on them to communicate with partners, clients, shareholders and others, as well as store corporate information, share files, and conduct a host of other operations. These applications are convenient, as their functionality is dependent upon online browsers.

However, web applications may have security weaknesses that can expose a single user or the entire organization to multiple threats. Cyber criminals have been focusing on the web in recent years and the trend continues to grow. Cyber attacks are becoming high-profile, getting more sophisticated, and increasing in frequency.

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

According to the Gartner Group, 75 percent of cyber attacks and web security violations occur through Internet applications. Regardless of the development of the application being outsourced or in-house, adversaries examine the infrastructure of an application and its design to identify potential vulnerabilities that can be exploited.

High-risk threats to web applications

In particular, enterprises need to be aware of the following threats to web applications. The focus is on the wide repertoire of techniques adversaries use to compromise web applications and sites:

DoS (Denial of Service): DoS attacks involve hackers overwhelming a web application with multiple requests for information, slowing down the operation of a website or entirely taking it down. A multi-source attack is considered a distributed DoS or DDoS, which routes the malicious traffic through a bigger number of servers. Attackers may also upload dangerous files, which may be downloaded by employees or processed in a corporate environment.

Cross-site scripting (XSS): This is a common vulnerability that exploits web application weaknesses to attack users. The attack involves hackers passing data that's crafted to masquerade legitimate functionality; without proper validation of data, malicious code is transferred to the web browser. In many cases, cyber criminals craft attacks via JavaScript, but attacks may also include Flash, HTML, or another code executed by web browsers. Cross-site scripting enable hackers to steal credentials, hijack sessions, or redirect users to malicious sites.

SQL injection: These are random attacks that target applications with weak security to inject malware to extract data or aid virus distribution. These two scenarios are often a result of poor programming. Successful attacks involve hackers modifying the logic of SQL statements against databases. The application, in most cases, builds dynamic query statements, enabling malicious users to work with the data. Consequences can include data corruption, account compromise, or even a complete host takeover.

Parameter & buffer manipulation: Websites often use URL parameters to pass information between web pages. Hackers can take advantage of this process and rewrite parameters in malicious ways.

They may also manipulate buffers (a small storage allocated for data), andoverload them so that additional data overwrites data in other areas. Hackers may also override data with their own malicious code.

Security policy template

Security policies are, in effect, a strategy to protect web applications and ensure availability at all times. These generally include steps to identify responsibilities, predict threat vectors, and determine prevention & mitigation methodologies. It is essential to define rules for ensuring high availability of applications and minimizing weaknesses.

Access and control mechanisms

It is common for web applications to lack sufficient authorization checks for people attempting to access their resources. In a secure environment, there should be both role based and user access controls. Organizations should ensure that users can't bypass ACLs by navigating directly to a file or page.

This can be done by setting ACLs to default grant or deny access to authorized users and roles. The IT team can also utilize vetted frameworks and libraries. Access and control should be kept separate, and custom authorization routines should be avoided, as they make the authentication of all necessary channels more challenging.

Delineation of responsibilities

Never assume there are predefined responsibilities to access files and data stored by web applications. A lot of testing and experience goes into vetted frameworks, encryption algorithms and libraries, so make sure there is a clear description of responsibilities for every user at every possible step. The more default the set of responsibilities, the more difficult it will become to securing the application.

Roles and access control are not just for developers, but for all people involved in using web applications. You need to have some delineation of roles with different levels of access for each user. While every organization's application development program will be different, responsibilities can be handled in different ways or added in different places, and still be effective.

Security resources and tools

A well-defined policy template includes the use of encryption algorithm for web applications. Users have to determine the data that is valuable enough for encryption, and identify vulnerabilities through threat modeling. Some resources may have to be sacrificed to secure highly sensitive data.

Implementations like a web application firewall will safeguard enterprise applications and websites from any cyber threat, so you can avoid costly downtime and data breach attacks. Enterprises are recommended to look for PCI-certified WAF as it protects against Cross-site scripting, SQL injections, and other threats. Some offerings include custom security rules that let you enforce security policies efficiently while eliminating false positives. New solutions are also using crowdsourcing techniques to protect applications with collective knowledge about the modern threat landscape. Threat information is aggregated using big data analytics.

Disaster recovery and emergency mechanisms

Disaster recovery solutions are required for immediate response to high-risk situations and mitigation strategies must be deployed to limit exposure from an attack. Disaster recovery should be allowed to bypass security assessments and address the risk before a proper assessment can be carried out. Patch releases, on the other hand, are subjected to appropriate level assessment based on the threats to the application architecture and/or functionality. CIOs are the personnel in charge of disaster recovery initiatives.

Emergency mechanisms may include steps to take the application off-the-web or stop functionality release into the live environment if multiple threats increase the risk to unacceptable levels. Emergencies should be addressed in a point/patch release unless other mitigation strategies limit exposure. Credentials after patching may be temporarily stored outside of the webroot until the application infrastructure is tested in updated areas of the application environment.

Other measures

When web applications feature hard-coded credentials, the user can store credentials in the form of hashes to improve security in case the database or the configuration files get breached. Strict ACLs can also be deployed to protect credentials. Enterprises should also use a whitelist of acceptable input commands.

If applications are configured to construct SQL queries, but include vulnerabilities that enable hackers to modify these queries, then it is beneficial to avoid dynamic queries, quote arguments, and special characters. The database inputs should be sanitized in general, and there should be strict rules for input validation.

Compliance measures and business benefits

When it comes to compliance, users who violate this policy should be subjected to a hearing, which may be concluded with a disciplinary action such as termination of employment, depending on the nature of violation. Everyone accessing web applications should undergo assessment as a requirement of a security policy and adhere to the policy unless exempted in certain circumstances.

The infrastructure of all applications should be updated to include the security control process. Any web applications that lack appropriate security controls should be taken down for formal assessment, and should not make their way online until the CIO clears them for security integration.

All these measures will result in business benefits, such as no loss of productivity during downtimes, and ensure SLAs are met. An enterprise with highly secured web applications will also attract more clients, as they would be better able to protect sensitive customer information.

Organizations following the security policy template would also enjoy technical benefits such as high availability and security of data. Both these factors are likely to improve client-wide and industry wide reputation. Lastly, the policy will bridge the gap between good IT practices and enterprise security compliance.