Security 4 Nø0bs — Rules of Engagement

Security 4 Nø0bs — Rules of Engagement

Know Before You Go!

Hola Friends,

In my previous post — Know Thy Scope — I wrote about the importance of understanding the purpose — the “why” — of a security audit / penetration testing engagement. Knowing what is in & out of scope will determine what needs to be tested and how far to go in the aforementioned effort to bring value to the client. Deviating from scope will often lead to problems.

Once the scope of the engagement has been identified, the next item of importance to know before getting started is the rules of engagement (ROE).

Rules Of Enagement Defined

Cambridge Dictionary defines the rules of engagement as “orders that soldiers fighting in a war are given about what they can and cannot do.”

As it relates to security testing, this translates to what a Security Analyst can / cannot do. More often than not, the Security Analyst will be allowed to create an account (if credentials are not provided), attempt to show proof of an RCE (remote-code execution), and compose a proof-of-concept that illustrates a vulnerability with some feature, component, or in the overall business logic … nothing more.

Before the start of testing, the rules must be expressed in a clear manner to the Security Analyst, by the Client, and there must be some measure of consequence should the ROE be violated. There must be zero ambiguity as to what the bounds/limits of testing will be. The output of understanding scope and ROE is a sign-off with definitive permission to proceed.

Know The Rules

So what are some of the ways to establish ROE, you ask? Well, it’s simple. Below are some questions that help me determine what the rules are and how best to understand the bounds of what is / is not testable. Also, what do when a compromise is found, and whom to contact. The ROE isn’t just a set of mandates on what is allowed / not allowed. It is also an answer on what to do when “x” happens.

These questions are by no means an exhaustive list. I’ve curated them from a wide range of sources (ie, lectures, YouTube Videos, etc.). I don’t pretend to claim them as original, but I have taken liberties to adopt them to fit my needs. I’m sharing them here so that you may do the same. Some questions I use are:

What is the target systems or Network?
What systems or networks are off limits?
What are the specific features or functions to test, based on risk?
What is the schedule? 
When did this need to be performed that won't interfere with dtd ops?
What actions are permitted / prohibited during the PT? The immediate "stops"
Who will be responsible for coordinating the PT with the other teams/departments?
When to escalate a P1 (Zero Day / RCE) find?
How will the PT be coordinated with the Security operations?
Who will be notified of the PT and when? Comms frequency, status updates, etc.
What are the consequences of violating the ROE?

If, as a Security Analyst, you are part of an organization that includes a separate department for business relations/customer support/sales, these questions (and more) will be handled by them.

The point here, is to have as much of an understanding about how the ROE is established, and what gets asked as part of that output. It is even more critical to understand that the purpose of the security audit/penetration test is to “prove” that a system can be compromised, or that there is a flaw in the business logic. Testing should not aim to take down the system or expose a security vulnerability publicly.

But don’t take my word for it … I’d love to hear from you. Leave a comment on your experience and/or thoughts on the fundamentals of the ROE on an engagement. Until next time …

ciao for now!