Know Your Limits

An application testing assignment often begins with a definition of scope, i.e., the boundary within which the security tester's abuse will be confined.  The final boundary typically gets drawn by the customer or by the customer and the testers working together.  For a given test, there are a number of ways to define this boundary; examples include the items in the following list.

 

-          A "deployable unit", i.e., the minimum set of files required for the application to run properly

-          A set of executable files , but not the database (or vice versa)

-          The portion of the application managed by the team that commissioned the test

-          The portion of the application NOT managed by the team that commissioned the test (e.g., third-party components)

-          The version of the application as it exists in its QA environment as opposed to the version in its pre-production environment or elsewhere

 

And, there's another way to look at it.  As organizations necessarily become more efficient and more integrated, their applications also become more integrated (some would say, entangled).  They no longer operate and communicate only within the walls of a single organization; in fact, such integrated applications may function properly only when their multi-organizational components function together.  And yet, security testing of these components is often performed independently and at separate times. Even worse, the communication among the interested parties can be minimal and, sometimes, defensive.   This piecemeal approach tends to leave openings for the overall application to be attacked.  Heartland Payment Systems certainly learned this lesson the hard way; you can read their story in the following Businessweek article: http://www.businessweek.com/stories/2009-07-06/lessons-from-the-data-breach-at-heartlandbusinessweek...

 

The real problem with this scoping and boundary setting is that it applies only to the "good guys”: the customers and their testers.  The "bad guys" honor none of these boundaries.  Consequently, it is possible that even the most thorough in-scope testing can leave a customer vulnerable to out-of-scope attacks.  So, what can be done?  Here are a few suggestions.

 

Measure

-          An organization should have a well-defined inventory of its applications.

-          The entire scope of each application should be measured, including all of its parts and pieces.

-          Measure each scope-limited test's contribution to the corresponding application's overall security status.

-          Factor these measures into the organization's overall security posture.

 

Work Together

-          Whether it be coders and DB administrators or business partners whose applications communicate, share the applicable security details.  Optimize the whole application's security posture, not just that of its components.

-          Work with testers who have the experience and skill to see and evaluate the "big picture".

-          Participate in organizations that facilitate safe, confidential information sharing.  Infragard is an example of such an organization; learn more about them on their website: https://www.infragard.org/.

 

In conclusion, practical considerations require security testing to be clearly scoped.  However, these individual tests contribute to a larger picture.  Seeing and understanding that larger picture requires meaningful conversations among all interested parties, whether within or among organizations.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Sam Denard is a Senior Security Engineer with HP Enterprise Security.
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.