Java Reference
In-Depth Information
created as part of the threat-modeling phase. hese detailed scenarios capture the possible vulner-
abilities that might aid the threat scenarios because of their manifestation in the Web application
and its environment.
here are some factors that need to be taken into consideration while designing, developing,
and implementing security functionality. he threat-modeling process has provided a great deal of
insight into the several threat scenarios, their impact, and possible vulnerabilities that might have
aided the threat scenario. Security controls need to be developed to ix the vulnerabilities that have
been identiied during the threat-modeling process. Apart from this factor, security compliance
and contractual requirements are also an important aspect for consideration. Security compliance
requirements and contractual and/or regulatory obligations need to be taken care of while design-
ing security functionality for the Web application, as the organization's competitiveness—or in
some cases, existence—depends on their adherence to these compliance requirements. In addition
to this, industry best practices may also be kept in mind while designing application security
controls. Several bodies such as OWASP, NIST, SANS,
*
and so on prescribe several security best
practices for network, host, and Web application security. hese best practices provide a real-world
implementation view and would aid greatly in the development of security functionality for the
Web application.
Once the controls are selected, it is important to create the inal set of detailed secu-
rity requirements for the Web application. his detailed security requirements document is
the inal deliverable from the risk assessment phase. his document must provide details
about the detailed security implementation and functionality that will be implemented for
the application. his is amalgamated with the requirements for the Web application, which
is the irst phase of the Application Development Life Cycle. he requirement phase of the
Application Development Life Cycle or SDLC focuses on the functional and nonfunctional
requirements of the Web application that is to be developed. Functional requirements need
to be formulated keeping in mind the type of application, its intended use, its scale and size
of operations, and so on. Security requirements constitute the nonfunctional requirements
of the application and are based on the type of sensitive data stored, processed, or transmit-
ted by the application and the risk of attacks to that sensitive information. hese two sets of
requirements form the total set of requirements for the Web application, following which the
design for the application is created based on the requirements and, further, the application
goes into development.
During the course of the application development life cycle, changes are inevitable for any
enterprise application. It is therefore essential for the architects and developers to revisit the risk
assessment for the enterprise application and update the critical information assets, threats, and
risk mitigation strategies, as the case may be. he risk management process its in quite well with
a typical change management cycle, where any changes to the application are irst discussed,
understood, and justiied in terms of impact and need and then implemented and tested. Risk
management should be built into the change management process, where the risk assessment
process is active during the period where the need for change is raised, feasibility evaluated, and
impact understood. Risk mitigation and continuous evaluation come into play when the change
is to be implemented, tested, and veriied.
While risk management is extremely beneicial for security, there is a single immutable truth
that needs to be understood. One can never mitigate every risk. As individuals, we tend to believe
*
NIST stands for the National Institute of Standards and Technology, and SANS stands for SysAdmin, Audit,
Network, Security Institute.
Search WWH ::
Custom Search