Protect Your Assets
Showing results for 
Search instead for 
Do you mean 

Know Your Limits

Samuel_ ‎10-24-2013 08:48 AM - edited ‎09-28-2015 10:53 AM

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:


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.



-          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:


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.

0 Kudos
About the Author


Sam Denard is a Senior Security Engineer with HP Enterprise Security.

27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all