EnterpriseSecurityArchitecture_WhitePaper

8/7/2019 EnterpriseSecurityArchitecture_WhitePaper

1/8

Enterprise Security Architecture Whitepaper

Enterprise Security Architecture

Managing Securit y across t he Lifecycle

John Pavone, Director of Accelerat ion Services

Aspect Security, Inc. (www.aspectsecurity.com)

Email: [email protected]

9175 Guilford Road, Suite 300

Columbia MD, 21046

Phone: (direct) 610-574-0736 (office) 301-604-4882

Whitepaper: Application Architecture as a Catalyst to Securing Applications

October, 2007

Introduction

The IT industry is doing a good job in patching the security holes in our networks and host operatingsystems. According to a recent Gartner study only 25% of the attacks seen today are aimed at the networkand host layers thats the good news the bad news is that our business application is the attackers newtarget of choice.

Are we as good at securing our applications?

Recently, the SANS Institute has made web application security the number one threat in their Top TwentySecurity Attack Targets (2006 Annual Update). The analyst community agrees, noting over 75% ofapplications are vulnerable and 70% of attacks are now focused on these custom applications. Custom

applications and services are the hackers favorite target. The technology is evolving and connecting soquickly that it has been very difficult for the security community to keep up. The attackers know this andtheyre taking full advantage.

Application security is challenging, and there are many tempting approaches out there. Were here to tellyou that if you want to get value out of your application security efforts, put a plan in place that will drivedeep visibility into application security. Then you can manage with metrics.

In our experience, organizations that establish an application security team are the most likely to succeed.The team should be responsible for both facilitating visibility and leading efforts to improve security.Typically, those teams do training, verification, process, tools, architecture, etc

Application Architecture Catalyst

Integrating application security with your application architecture functions provides reuse and a costeffective approach to securing applications. The application security function should work closely with theapplication architecture team to improve application security. Compare this with a reactive approach thatdeals with application security late in the lifecycle. This penetrate-and-patch approach is significantlymore expensive and will never address the root causes that lead to applications security problems. Insteadof treating the symptoms, work with application architecture to eliminate application security issues beforethey are a problem. Application architecture can be a catalyst to securing your portfolio of applications,providing many of the fundamental people, process and technology capabilities required in improving yourapplications security posture.


2/8


1 Applicat ions are Vulnerable

Many organizations rely on the underlying infrastructure to protect their applications. These lead to what welike to call the top 5 myths of application security. If these sound familiar in your organization, its time toget serious about application security.

1. Perimetersecurityworks myapplicationissecurebecauseitsinsidethefirewall.

2. Securityisaninfrastructureproblem.

3. ProductXhandlesAAA(Authentication,AccessControl,Accountability)formyapplication.

4. Developersdontneedtounderstandsecurity.

5. Scannersachieveprettygoodcoverage.

Attackers can by-pass your infrastructure security by simply following the security rules of theinfrastructure. This may sound somewhat recursive or self-defeating, but if attackers follow the simple rulesof a web applications primary protocol, HTTP, many infrastructures would accept these requests and passthem along to the application. This places your application in the direct line of fire of an attacker. Is yourapplication vulnerable to these attacks? How about the OWASP Top Ten?

The OWASP Top Ten

The OWASP Top Ten provides a powerful awareness document for web application security representing abroad consensus about what the most critical web application security flaws are. Adopting the OWASP TopTen is perhaps the most effective first step towards changing the software development culture within yourorganization into one that produces secure code. The statistics on the OWASP Top Ten are ridiculous --90% of applications have XSS (cross-site scripting). We find serious issues in every application we analyze(and thats a lot). The following is the 2007 edition of the OWASP Top Ten:

A1 - Cross Site Scripting(XSS)

XSS flaws occur whenever an application takes user supplied data and sends it to a web browserwithout first validating or encoding that content. XSS allows attackers to execute script in the victim'sbrowser which can hijack user sessions, deface web sites, possibly introduce worms, etc.

A2 - Injection FlawsInjection flaws, particularly SQL injection, are common in web applications. Injection occurs whenuser-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile datatricks the interpreter into executing unintended commands or changing data.

A3 - Malicious FileExecution

Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data,resulting in devastating attacks, such as total server compromise. Malicious file execution attacksaffect PHP, XML and any framework which accepts filenames or files from users.

A4 - Insecure Direct ObjectReference

A direct object reference occurs when a developer exposes a reference to an internal implementationobject, such as a file, directory, database record, or key, as a URL or form parameter. Attackers canmanipulate those references to access other objects without authorization.

A5 - Cross Site RequestForgery (CSRF)

A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to avulnerable web application, which then forces the victim's browser to perform a hostile action to thebenefit of the attacker. CSRF can be as powerful as the web application that it attacks.

A6 - Information Leakageand Improper ErrorHandling

Applications can unintentionally leak information about their configuration, internal workings, or violateprivacy through a variety of application problems. Attackers use this weakness to steal sensitive data,or conduct more serious attacks.

A7 - Broken Authenticationand Session Management

Account credentials and session tokens are often not properly protected. Attackers compromisepasswords, keys, or authentication tokens to assume other users' identities.

A8 - Insecure CryptographicStorage

Web applications rarely use cryptographic functions properly to protect data and credentials. Attackersuse weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

A9 - InsecureCommunications

Applications frequently fail to encrypt network traffic when it is necessary to protect sensitivecommunications.

A10 - Failure to RestrictURL Access

Frequently, an application only protects sensitive functionality by preventing the display of links orURLs to unauthorized users. Attackers can use this weakness to access and perform unauthorizedoperations by accessing those URLs directly.


3/8


2 Applicat ion Security Challenges

Securing applications becomes a daunting task for most organizations. The sheer number of applications,lines of code and architecture variations combined with the specialized skills and knowledge required tosecurity assess these applications leave information security and IT management at a loss. The challengesof application security include knowledge / understanding / skill-set, technical complexity, and scaling.

Know ledge / Understanding / Skill-Set

Many IT professionals are not trained in application security so defining what needs to be fixed / changed inthe way we develop applications fall on deaf ears. Training requires careful planning to make sure the rightmessage and direction is being delivered. In our experience hands on training specific to the developersprogramming platform is most effective.

Technical Complexit y

Determining or assessing whether an application is vulnerable to attack is complex and requires specializedskills. Developers do not think like attackers, so augmenting their skill-set to do this type of analysis isdifficult with only a few being able to make the transition. This causes the basic economic problem of supply& demand low supply of security analysts with high demand.

Scaling

So, an organization needs to train the masses, hire specialists, and get their arms around the applications intheir portfolio, all within budgetary constraints. Typically, a mid-large size organization has hundreds ofapplications, millions of lines of code and varying technologies and architectures. How do you get assurancethat the applications are secure while keeping costs in check?

3 Approaches to Application Securit y

In our experience weve seen many approaches organizations take in achieving security in their applications.

The Silver Bullet

The first approach many organizations take to securing their applications is to find a product that willautomate the assessment of the applications already in production as well as facilitate the developer inbuilding secure applications -- the silver bullet. This seems like a viable solution and many are seduced byits appeal to quickly provide coverage at a low cost. The reality is automated tools do provide a valuablecomponent to the application security plan but they do not offer the assurance coverage required and endup costing more on intangibles like tool training, managing false positives, and overall buy-in from thedevelopment community. Automated tools are not the silver bullet for application security, but cancompliment an overall security plan.

Penetrate and Patc h

Organizations that are introduced to application security through actual production incidents quickly go on a

reaction based plan and remediate their issues with a SWAT team approach. They bring together theirbest IT technicians paired with outside security consultants and fix their most critical applications inproduction. This usually carries a high cost but remediates quickly. This approach does remediateproduction vulnerabilities, today, but without proper analysis and planning may not remediate root causes Treating the Symptom. Providing enterprise based security controls and augmenting developmentprocesses to define and design with security in mind establishes a repeatable and consistent approach toapplication security. The SWAT team approach may fix vulnerabilities today, but they typically reappearover time.


4/8


One at a Time - Ad-Hoc

A small penetration test team is formed, tools are purchased and theyre ready to assess applications.Communication is sent out to the development community and if the application teams think about it or thebusiness forces them to, the penetration test team will assess their application. This is what we refer to asthe Ad-Hoc approach. It does provide for a repeatable and consistent security assessment process, buttheres no priority or plan of execution in order to know whether your critical applications are secure and

dollars are being spent wisely. Securing one application at a time does not work without an overall priorityand execution plan.

Need an Application Security Plan

All the approaches above offer application security capability, but in order to improve an organizationsapplication security posture, a security plan across people, process and technology is needed. This usuallybegins with establishing a dedicated application security function (team) to address and formulate a plan.The plan must establish a line of site from policy to implementation, cover the entire application portfolio,manage improvement through metrics, and most importantly, invest in people, process, and technology.

4 Applicat ion Securit y Team

Many organizations, particularly in the financial industry have established teams that focus on variousaspects of application security. This trend started about 2002 and has continued to grow slowly for the pastfive years. At this point, a majority of financial institutions have a specialized application security team ofsome sort. There are many types of these teams, ranging from small 1-2 person teams to larger groupswith a core team and an extended team of field architects.

The Application Security Team role is to improve the security of the organizations entire softwareapplication inventory by discovering and managing application security risks. The team also encouragessecurity improvements to the people, process, and technology involved in acquiring, building, andmaintaining applications.

People and Teams

The Application Security Team provides a critical single point of focus for an organizations application

security efforts. A key foundational element is for the team to establish a security awareness and trainingprogram for developers, managers, and architects. The team will also provide subject matter experts (SME)support to development projects. Finally, the Application Security Team will be responsible for keepingmanagement apprised of the state of application security across the organization.

ProvideApplicationSecurityAwarenessandTrainingProgram

ProvideApplicationSecuritySMEsandSupportServices

ReportonApplicationSecuritytoSeniorManagement

ManageApplicationSecurity

Process

The Application Security Team also plays a critical role in defining and implementing process improvementsdesigned to more reliably create secure software. The team will establish a set of application securitypolicies and standards, and then perform various reviews throughout the lifecycle to ensure they are beingfollowed.

IntegrateSecurityActivitiesintotheApplicationDevelopmentProcess

ProvideApplicationSecurityAssurance(Verification)Reviews

StewardApplicationSecurityPolicyandStandardsFramework

MeasureandImproveProcessEffectiveness


5/8


Tools and Technology

The Application Security Team is in the best position to establish an application security portfolio thatindicates exactly which applications are the most critical. The team should also work to standardizeenterprise security controls and APIs, to maximize reuse and assurance. The team should also identify thesupporting tools, such as vulnerability and code scanners, and play a major role in determining how they areto be used.

ManageApplicationPortfolio

EstablishApplicationSecurityKnowledgePortal

EstablishEnterpriseControlsandAPIs

InstitutionalizeStandardApplicationSecurityTools

5 Synergies w ith Application Architect ure

So where does application architecture come into play? There are many synergies between applicationsecurity and architecture functions. Application architectures need to understand the business plan,inventory applications, and establish a consistent and repeatable approach in the design and implementation

of applications. The process they follow can be leveraged by application security to provide a quality based,consistent and cost effective approach in fulfilling the application security plan.

Leverage people

Application security can virtually scale their staff by leveraging application architects as security analysts.They offer the closest skill-set and usually look at problems from a macro-design viewpoint. The architectsare also in the development community and have established working relationships, providing the muchneeded buy-in from developers.

Utilize exist ing processes

Application architects are already integrated within the application development process conducting design /architecture reviews and planning activities. Augmenting their reviews to provide security relevant

assessment provides early assessment activity and broad coverage.

Design w ith Security in Mind

Understanding an applications technical and business profile determines the level of inherent risk. Much ofthis information has already been collected by application architects and could be leveraged to prioritize thelevel of security assurance required across the portfolio. Application architectures can be reviewed withsecurity in mind establishing and enforcing secure design patterns, standards and implementations.


6/8

6 CoAn appliccontinuou

1. Define

You havetrying toto the imApplicatioapplicatio

tinuous I

tion securitys improveme

w hats Im

to establish schieve a linlementationn architecturs.

provem

plan should it process. T

ortant t o Pr

ome prioritiesof sight froetails. Thatartifacts can

nt Proce

prove the she following

otect

, and that myour enter

s the only wabe leveraged

ss

curity posturiagram depic

ans understarise level secy to know thto define crit

Enterprise

e of an organts a 4 step c

nding whatsurity concernt youve effeical assets &

ecurity Archi

ization by insntinuous imp

important tos all the waytively addresfunctions acr

tecture White

ituting arovement pla

protect. Youhrough the lsed all the risss the portfo

paper

n:

reyersks.lio of


7/8

2. Estab l

Applicatiopeople anintegratincapabilitie

3. Verify

Thinking lthreat moa consisteexperts cfacilitatethese key

implemen

ish Securit

n security usd process con

them into as can also be

Security an

ike an attackdeling, vulnent and repean provide suode reviews,security acti

tations. Auto

Controls

s a number otrols. Applicrchitecture deleveraged by

d Diagnose

r is a difficultability assessable securityport servicessecurity testiities will prov

mated tools

f different cotion architecsigns. Applicapplication s

Risks

skill-set to ament and risfunction. Utito the applicg and archit

ide insight on

rovide a valu

trols. Manyure can direcation architeecurity.

quire. Definianalysis int

lizing applicatation teams icture/designthe applicati

able capabilit

Enterprise

re technical,tly address thture teams a

ng security athe develop

ion architectsperforming

reviews. Haons risk post

y in data coll

ecurity Archi

but dont fore technical cnd process im

nalysis proceent lifecycle

as security sthese tasks.ving the archire leading to

ction and co

tecture White

et about thentrols byprovement

ses includingwill help esta

ubject matterArchitects catects involvesecurer

erage.

paper

blish

in


8/8


4. Analyze Metrics and Improve the Organization

Metrics should be collected every step of the way. Metrics can measure the effectiveness of the applicationsecurity plan from which management can make key decision on direction and budget. Metrics shouldaddress people, process and technology improvements including application coverage, risk management,and training.

7 A Catalyst for Application Securit y

An organizations application architecture function can provide critical benefits to the application securityplan. Leveraging the existing people, process and technology activities provided by many applicationarchitecture functions gives the application security team a jumpstart. Benefits include cost effectiveness,higher quality, scaling and flexibility in staffing, and an overall better security process.

About the Author:

John Pavone has been an IT professional for over 20 years. In the last 12 years, John has concentratedsolely on Information and IT Infrastructure Security. John works for Aspect Security, a leader in the

application security consulting space, as a practice lead specializing in the enablement of application securitywithin organizations. John held various security related management positions, including the chief securityarchitect for a large financial services firm. In this role, John established an enterprisewide IT securityprogram utilizing a quantitative risk assessment and mitigation approach with a direct line of sight to theorganizations corporate dashboard. Other major accomplishments include the development andmainstreaming of an IT risk management process, the creation of an application vulnerability testing lab,and the security design and implementation of an enterprise single sign-on and authorization system.

Documents

EnterpriseSecurityArchitecture_WhitePaper