Web Application Security Testing
.. is it that hard to integrate security into SDLC?
Web Applications (Useful Applications which can be served in Web 2.0/3.0) today are rich and serve an intended purpose - be it to serve an ecommerce website or host a collaborative API to re-create something useful using new ideas for people and by the people. It’s completely safe to assume web applications should have a generic SDLC (software decelopment life cycle or system development life cycle) compared to that of software (as in thick client) and not surprisingly - they do!
Software go through phases of development which is known as the SDLC
and represents how a particular task is carried out periodically and efficiently for better code productivity in terms of functionality. A generic overview process of a SDLC is to break tasks into pieces so that they can me managed well and later integrated into a complete working product which can be used for the intended consumers of that product. Similarily Enterprise Web Applications go through application development processess and on each of these phases of the entire process, seperate developers working on an unit is responsible for that particular code and hence is the code maintainer. SDLC
isn’t short and static at Enterprise level but get’s worse and complex when phases begin to shift from one stage to another. There are main ingredients such as:
- Functional Project Management
- Technical Project Management
- Information Security Assurances
- System Integration Test Plan/Integration Test Cases
- User Acceptance Test Plan/ Acceptance Test Cases
.. and most of what everyone else knows and what project managers are theoritically trained to prepare for boils down to:
- Planning
- Requirement Analysis
- Design
- Development
- System Integration
- User Acceptance and Parallel Testing
- Implementation
- Operations and Maintainence
All of the aforementioned are packaged into the five super’s i.e. functional project management, technical project management, information security assurances, system integration test plan and integration test cases and user acceptance test plan and acceptance test cases. We are more worried about Information Security Assurances and not long far in this way - we’ll be introduced to how information security is governed and where SDLC is outruled by it’s superset, and when precisely *security is to be placed into SDLC
thoughfully by it’s governing superset.
##But the Question Remains ..
How Enterprise Web Application SDLC are any different from Software Product Based SDLC? and how shall security governance take place during the entire lifecycle? Enter ALM - Application Lifecycle Management
. To cut short of everything else and leave details to it’s own research place:
Enterprise Web Applications differ in production, business case, and it’s relative uses than that of a product applications. To elaborate - web applications might die fast due to it’s trend nature, user acceptance or short life use case - which means as long as the trend survives, the web application survives, product software whilst might have core re-use functionality in operating systems (e.g. Microsoft Word? OpenOffice? ..). People leave Orkut to go newly obtained trend of Google+ and might never get sick of
#hashtags
at Facebook but they never leave productivity software suite installed in their PC/Laptop for general core functionality use.To take care governance for both - Web Application Security as well as Software Security or for that matter all the five super ingredients we talked about earlier - we have
ALM
and it’s really not equal toSDLC
.ALM
could be considered as the top gem mounted above theSDLC
, whereSDLC
lies in the bottom looking up at theALM
to manage it’sgovernance
,development
andoperations
. TheALM
has control of theSDLC
- andSDLC
has control of themodular software/application deployment
.
##Shritam! don’t tl;dr ALM ..
.. and so I won’t. ALM
as you now know is Application Lifecycle Management
, it’s easier to think of it as a superset of SDLC
. If SDLC
takes care of the operational part, the ALM
takes care of it’s governance. It’s important to understand that security
from it’s very core has to be governed and regulated in authoritive perspective or code maintainers would continue to write bad code - and this exactly is what happens to the most applications - be them web application or applications/products in general!
The three aspects of ALM
is to provide:
- Governance
- Development
- Operations
And all of these three factors are essential to run the show for SDLC
, and ofcourse SDLC
sometimes depend on it operationally if not for entire development (ever wonder about DevOps
?). This is exactly where security professionals should be looking at! If one looks deeper thoughfully, any development criteria is only fullfilled by authorized operational means and if operationally security is placed forward - the secure development will become mandatory. There is a reason why I introduced ALM
here because in layman terms:
If project managers care not to outrule their developers to enforce security internally and make it mandatory, someone else have had got the system processes broken already!
Back to ALM
basics, what we have is a raw idea which has a potential to either become an end-product for it’s consumers and accepted by the massess in core functionality or it dies out and serves a short span of life to benefit from short-term use case/business case.
If the security problem
at operation level has been identified, let’s not forget to take a submarine-dive to explore what’s beneath ALM
.
###Governance for ALM
Take a sweet note - authorities always have a higher ground and what they only know is business, be it short termed or long termed - as long as it’s beneficiaries are transparent, people will invest into the project. In ALM
, to escalate ideas into businesses, there has to be a purpose; An application has to serve a purpose and then it should have a business value - this is the business use case
. Everything else is High-Lower authority for the entire project and they are project portfolio management
and application portfolio management
.
What they do specifically as part of the governance are simplified here.
Business Case Development: Business Authorities hold the investment share, they have the equities, they know the business, they have stolen the idea ( .. or have them originally perceived!?) and now they are ready to invest on this BIG-O-BANG idea and wish not to lose out on the competitor game. They decide the finances. This first serious move is known to be Business Case Development
or BCD
.
To support the idea, there are peers who do the analysis for them (business authorities) and chalk out business use for the idea and if they are beneficial to the investors. If they are, business case is approved and application development might now proceed.
Project Portfolio Management: The people who might have originally perceived the idea, might not have his/her own abilities to implement and transform it into a working product. They need someone else to do it for them and hence people
, processes
and product
become the essentials for any organization.
There are two ways Project Portfolio Management
or PPM
is carried away - either a project manager
is assigned the task with relative technical abilities to regulate a group of people who become the core team
of that particular project or there is a dedicated PMO
(Project Management Office) to regulate procedures at this level. Here actual development begins.
Application Portfolio Management: If Application deployment is over, it’s now an asset
to the organization and more importantly the investors who have invested money into the project. There needs to be an ongoing check on it’s beneficiaries and costs plus measures to check if the trend isn’t dying and flipping out of it’s way.
APM
or Application Portfolio Management provides a gateway to manage ongoing operation products, provide regulations around major revision (application or end-product software, as the case may be!) changes and perform updates keeping it’s business use case
in track and perform regular checks on it. If the trend persists, and the end-product or the application is feasibly performing well, updates for better performance, or added functionality is rolled out or a major updates are issued and released. This again needs checks from both PMO
(or PPM
) and BCD
.
Now if we look down here, pretty much during the whole process of life start to life end of the application development or software application end-product development - the governance
is constant and does not die out; and this also includes SDLC’s in-between (during which the governance
hasn’t died out either! and as described SDLC is only a part of the entire process).
###Development for ALM
Yet again, take a sweet note here - it’s not always feasible or necessary for an organization to stick to traditional SDLC i.e. RAD
, Waterfall
, etc. Iterative
might be sometimes the need of the time and more modern organizations have been using them.
Development is a fundamental necessity for any custom web application
, an Enterprise Product
or any End Product
and this is precisely the security gone wrong
point which has SDLC
phases in it. During the entire ALM, the SDLC
is a part of the lifecycle and it’s this point where security professionals
should target and permanently set a reminder for a security cross check
.
Now, as talked before - generic SDLC
has seven phases and equally there are seven security solutions to neutralize security risks
specifically at those places.
As to keep security point-of-view
in reminder, here are the clauses for these specific security solutions at specific phases of a SDLC:
- Code Review
- Risk Analysis
- Penetration Testing
- Risk-Based Security Tests
- Abuse Cases
- Security Requirements
- Security Operations
Security Operations
will be talked about when we discuss on Operations
segment of ALM
where it’s an integral ongoing security process. Based on what we have covered so far, we have code review
which is to be placed during developing code (development) and this can have:
- static code analysis and review
- dynamic code analysis and reviw
.. and then there is Risk Analysis
which is covered both during requirements/use case planning and architectural design. Penetration Testing
is to be done both and as part of testing
and maintainence/feedback from the field
which if elaborated falls under the following types of tests:
- black-box penetration testing
- white-box penetration testing
- grey-box penetration testing
- glass-box penetration testing
To really define these and cross the margin more:
A black-box penetration test
means there are no external or internal informational put upfront and security professionals should identify and abuse security loopholes externally and if required offensively go indepth of the flaw which means exploiting necessary security flaws to it’s deepest extent.
A white-box penetration test
means there would be full feedback from the developers or ALM
project managers to pin-point resources of interest and if required additionally provide access credentials to security test restricted zones. This sometimes is the industry de-facto because it’s efficient.
A grey-box penetration test
means to provide necessary resources of interests while the penetration testers are encouraged to find security flaws on their own but not limiting them to be short of credential request, if necessity be!
A glass-box penetration test
is new modular penetration test where security test monitoring
are placed (often times automated) and people monitor the activities of penetration testers while penetration testers are performing the test.
Risk Based Security Test
is a suite of Security testing for test plans that are prepared which has to be formulated into the development code, the code is at staging area and isn’t gone productional yet. Abuse Cases is where testers pre-discuss how a certain business model could be abused and in what ways it could be defended providing the right solutions in very early phases of the SDLC
which is Requirements Planning and Use Cases Development. Security Requirements
as fit as per the necessary feedbacks from abuse cases
and also performed for Requirements Planning and Use Cases Development phase.
Now if the Mammoth Security Gap Problem has been accessed right and the equation is to solve this security gap, SDLC
is specifically where security professionals should start looking at and because this now has been scientifically proven and deduced out!
Back to ALM
, the part of lifecycle which we discussed have SDLC
and this is where Security gap exists. There is another part of the problem which has to be ruled out and i.e Maintainence
. As developers begin to write code and business case demands more functionalities, more code is generated using frameworks and these in turn have adverse effects ranging from introduction of vulnerabilities from frameworks itself. Code Maintainence
have two popular entities:
- Updates
- Patches
.. and both of them could do either of the following:
- either break functionality and feasibility
- or break security without letting anyone know
.. and both of the aforementioned isn’t preferred. This is exactly where ALM
has another level i.e. Operations
where for specifically security
concerns, an organization should have a security operations center
to identify vulnerabilities and threat them.
###Operations for ALM
No more sweet notes, it’s tl;dr: DevOps
.
Soon after applications are deployed from staging
to production
, they start receiving patches
and updates
. To cope up with these the application has to be managed throughout it’s entire lifecycle and is now bond with the developers and the development team. The people who take care basically of both are DevOps
and a security operations center
here should be excactly placed here to do a routine check of patches
and updates
and release security fixes
for updates
, patches
or deployment code
as well.
And in this way security management
is closely packed with SDLC
and SDLC
is pushed forward keeping security as a process and not as a product. This should be the case but ..
##is security testing an intergal part of most organizations?
And Now we have been asking the right question.
v1.5.2