application , compliances , security , web-services

Web Application Security Architecture Considerations

September 23, 2012

Web Application Security Architecture Standard

Corporate’s business functions rely upon the integrity, confidentiality, and availability of its computer systems and the information assets stored within them.   Responsibilities and procedures for the management, operation and security of all information processing facilities must be established.  This standard supports the stated objectives.

Roles & Responsibilities

The Development Security Lead is a member of the development team that will be the main point of contact within the development team for security related questions throughout the software development lifecycle.

The Security Advisor is not a member of the development team and guides the team in following the secure coding practice.  The Security Advisor will perform the final security review approval.

The Project Manager communicates security information to all teams and ensures security pushes are scheduled and performed.  They keep QA and development of changes in security practice.

Quality Assurance tracks software defects and security vulnerabilities separately and communicates them to development.

The Information Security Department will assist End Users and IT Custodians in assessing, defining, implementing, managing and monitoring appropriate controls and security measures.

The Information Security Department will audit and review the adequacy of controls and security measures in place to measure and enforce conformance to this standard.

Web Application Security Principles

The following software security architecture principles should be considered when designing applications at Corporate.

  1. Fail Safe – Your application must always fail safe. That is to say if it encounters a situation and it can no longer proceed, it must deny access to the resource. For example, if a firewall cannot validate the action that is being requested by the requester, it should reject the operation; this is known as fail close or fail safe.
  2. Security through Obscurity does not Work – Obscurity should not be used as the only or primary security mechanism.
  3. Simplicity – Complexity increases the potential risk of problems. Application architecture and implementations should be as simple as is practical. This also makes it easy to do the right thing.
  4. End to end security – Where data requires protection during transportation, it should be enforced from the sender to the recipient (end to end).
  5. Compartmentalize – Applications should compartmentalize user access. Compartmentalization provides user access to data and functions that they require and restricts them from accessing data or functions they do not need.
  6. Defense in Depth – Applications should use multiple layers of security. This ensures that if one security mechanism is vulnerable to an attack, an additional layer will still enforce an adequate security policy. Password files for example, should be restricted by access control lists and encryption. Similarly even if data is validated, the use of stored procedures or prepared SQL statements is strongly recommended since it adds an additional layer of defense.
  7. Least Privilege – Applications should run with the minimum amount of system privileges that they need to function. Where elevated privileges are required they should be granted for the minimum period of time they are required. A similar principle is the “need to know” principle. Ensure that only the minimum number of people have administrative level access to production web, database and application servers.
  8. Trust but Verify – Applications need to trust other applications or objects on the same host or on the network, however, they must always verify the source they are trusting. The same also applies to users and their actions. For instance, before performing any administrative action, it is important to check that the requesting user is indeed an administrator authorized to request such an action.
  9. Think Strategically – There are no security silver bullets. Security requires constant monitoring and improvement and is not somebody else’s responsibility. Pay special attention to architecting the right solution so that it maybe reused frequently. The use of software design patterns and frameworks like JAVA Struts are therefore strongly encouraged.

https://www.bestitdocuments.com/Samples