“CORE”: APPLICATIONS (WEB, MOBILE) & INFRASTRUCTURE SECURITY

To create sound application security architecture and design it’s crucial to understand our scope. Are we auditing an application for bugs, or are we dealing with advanced attack scenarios and threat modelling in application deployment?

We need to understand what is important to prove, validate and protect. This thus starts to draw on capability rather than simply executing a “web application test” and filling checklists to find and report bugs.

We need to establish whether fundamental principles of design are baked in, where areas of concern are from a business and technical perspective, and to understand and model test cases accordingly.

Naturally applications are very different to that of infrastructure, but the mentality and approach is very similar. In the sections following we will explore Chaleits “Core” Capabilities and thought-leadership around testing / auditing / breaking applications for our clients.

Pre & Post Auth: How Can Basic Controls Be Broken?

Many security testing programs involve assessment that is generally from the “outside in” (external threat), initially from a pre-authentication perspective to see if it’s possible to “break-in”. Depending on the findings, post-authentication testing could take place either by using a compromised account within an application or being granted credentials that are used to do further assessment work.

Authorisation Issue Testing: Bringing a threat modelling mentality to multi-users / role-based applications and their URLs / APIs therein is critical. Pre-planned application “abuse cases” for both ROLE-BASED and FUNCTIONAL tests are considered. Let’s explore some simple derivatives:

• Horizontal: Within a user account / customer account, what modules are accessible? What features do are available? What actions can be performed on them? What parameters are passed? Are they predictable? Can we see others information? What Horizontal escalation is available with the same privilege level and same level of access? Can user’s data be seen and modified?
• Vertical: Is there data that should be read only for the user, but still can be manipulated? Is there manager role abuse? Can what manager can approve be approved? Can privs be escalated?
• Module Transversal: Can other aspects of an application not intended for a user be accessed thus reach other modules? What different modules can be accessed from this point, with higher privileges, even as other users?

Unicode Normalisation: Does the application normalise the user supplied input? Let’s test to see if functionality can be misused and thus create / update a user. Does the application allow the user to use any special Unicode characters?

Crypto-Related: There are usually a lot of issues and mistakes in applications given the complexity of the subject. Let’s dig deeper and examine for known plain text attacks, padding, ACL related attack etc.

Attack Chaining: This is where we combine our findings that on their own are not necessarily issues (perhaps low and medium issues) to overall construct (chain) an effective attack. It involves creativity in chaining various pieces of information together including role, privilege or system access to architect and potentially form into an elegant attack.

Advancing the Model: As progress is made, new use/abuse test cases build as we get to know what the technology stack of an application architecture. Value is created above and beyond OSWAP, OSSTM methodologies and standard XSS SQLi bug hunting.

Complete Mediation Strategy: Traditional pen testers often use standard methodologies to test parameter values. But what about the next step and test the parameter itself? Mapping the identifiers aka how the application changes the behaviour when input is supplied is key; i.e. when a user log is the identifier the application is creating / maintaining (access modifier) does that uniquely identify the user?

Subject–Object Matrix: This plays an important role in how applications change their behaviour according to the input that is supplied. For example:

• How does an application create a session ID?
• What is the subject-object action value?
• Are subject objects being tested and validated at each and every step? i.e. page load, record, object, other events etc?
• Is there an “Initiate, Review, Approve” model correctly in place?
• Are validations being executed correctly and are they continually verified (aka is the subject-object matrix being tested at each step according to the developer defined workflow for each application)?

Our capabilities are not just buried deep in applications and associated architecture. Security testing is about managing risk and risk itself is both a subjective and objective term based on appetite, perception, threat (real or otherwise) and compliance. Not all stacks, infrastructures, data storage architectures, and devices can be tested all the time for everything and that’s just a simple reality.

Compliance: Compliance testing mandates a set of key testing regimes against specific scopes and is highly dependent on the requirements of the Compliance framework itself. Whether the test is needed for PCI compliance etc., we establish the appropriate scope, depth and cadence needed for your compliance testing, in combination with other aspects of risk or applications that may not be applicable just in compliance testing.

Vulnerability Assessment: Fundamental to Technical Security Testing is the art of Vulnerability Assessment and seeing the “wood for the trees”. “VA” is more than just a suite of tools, it’s about the discovery, validation, contextualisation, and deduplication of the landscape of security bugs that are present in an overall environment.

A Bigger Picture: Vulnerability Assessment is the starting block for wider Assessment Services such as Attack Modelling (part of the Threat Modelling piece) and the beginning of a part of a wider Penetration Test. Interestingly, Vulnerability Assessment also pertains to the wider context of vulnerabilities in business logic and rules-based engines.

What Really Matters: Many of our more mature clients have Vulnerability Assessment engines already in place but the fundamental problem is coping with their output as they do “find stuff”. The art is in assimilating these findings, contextualising and prioritising them to give an overall technical risk framework. By blending both technical skills, the use of tools, and our wider Assessment and Strategic services, our capabilities expand to advising clients on both optimising their VA toolsets, vulnerability and asset management programmes, and in some instances embedding expertise to help run such estates.