Web Application Security Testing the Lares Way
The following blog post summarizes some of the key points from the first extracted session of the inaugural Lares Customer Summit that took place on Wednesday, December 2nd, 2020. We hope you enjoy the excerpted highlights of Zach Grace and Rick Tortorella session on web application security testing at Lares. The extracted session is available at the bottom of the page.
Getting Started
Lares web application security consultants adequately set the stage for testing by asking the five Ws: Who, What, When, Where, and Why.
So the Who. Lares’ consultants are hand-selected for a tailored fit to each engagement’s needs. Each consultant brings years of security and technology expertise to deliver a high-quality assessment. But an engagement cannot be successful without the help of a client. Client resources are needed to help shape and scope the engagement, create and grant access to the application, and resolve technical issues during the engagement. And importantly, we need to establish the necessary communication channels to ensure continuity throughout the assessment.
The What. We next determine what the client wants us to test. What application types (e.g., web, mobile, APIs), technologies, components, and even sub-components needed to ensure appropriate testing coverage. Does the client require specialized testing, e.g., IoT/IoE, SCADA, or source code analysis? Understanding project requirements (i.e., the WHAT) then is essential for Lares to tailor engagements appropriately.
The When. When is testing most suitable for the client – times of day and time zone of tester and clients, after business hours? Do timeline drivers exist, such as regulatory or contractual deadlines or product releases? Getting the ‘timing’ right can be a key parameter for ensuring the client’s testing needs’ are met.
The Where. Clients’ most pressing question is whether Lares consultants should test in production or non-production. There are PROs and CONs to each environment. A PRO for production testing is that we assess the real environment; the same environment threat actors are most likely to attack. CONs consist of a few counterarguments against testing in a live production environment. Impacts to live users or unobservable modification of data are two often cited concerns. Data privacy issues are a concern of business stakeholders when weighing testing options. Testing in the production environment could result in unintended exposure/disclosure of sensitive data. Further, legacy platforms or environments with unsupported technologies require more outstanding care in testing.
As for testing target applications in non-production, a PRO perspective is testers can ensure, to a degree, limited or no downtime or customer impact. A CON to non-prod testing is that organizations tend not to completely replicate production environments in test environments, thereby limiting assessments’ effectiveness. The absence of production technologies in development or testing environments may skew results and cause consultants to miss flaws. Additionally, organizations tend to focus less on completing the installation of ancillary services or misconfigure them, which inhibits testing. Further, consultants often encounter access issues with non-production instances compared to those typically found when testing in production environments.
The Why. Several testing requirements determine why clients call us for assessments, but a few common ones stand out. Clients tend to require us for cyclical testing, regulatory compliance mandates, or validation of program security maturity.
The Color of Web Application Security Tests
Our testing covers engagements that range in type from Black Box (Zero-knowledge), Grey Box (Credentialed), and White Box (Credentialed/Source-assisted – full knowledge). As Black Box testers, we simulate an external actor’s attempts to exploit a target application or device. As Grey Box testers, we simulate authenticated external and internal actors with multiple user access levels to achieve a greater depth of testing – more comprehensive than black-box testing. Grey box testing requires assistance from the client to provide assessment assistance. For example, we might need account creation (reflecting the range of roles in an application), firewall configuration to facilitate needed access, and the addition of IP addresses into a whitelist. In White Box testing, we simulate all threat actor types, including the ‘disgruntled employee,’ to test for functionality issues, abuse cases, and unintended impacts identifiable with full admin rights. Additionally, the client provides full documentation, including source code, in White Box testing.
How We Test
Lares performs reconnaissance to achieve a thorough understanding of our target application. Then we proceed to the attack and exploitation stage, where we target authentication and authorization, input validation, and functionality (e.g., business logic flaws, sensitive data leakage, and platform testing). The manual pieces are "the fun tasks for us!" because we understand the business impact of the findings. We uncover the business logic missed by scanners and pass this perspective on to our clients for contextualized remediation.
Deliverable Deliverables
We provide actionable content deliverables upon completion of our engagement with the necessary evidence and recommendation for remediation. The content includes a high-level description of findings along with detailed replication and remediation steps. The reports can stand on their own, but we can help clients focus on highlights via debriefing sessions.
Takeaways
I believe you will find additional insights from the Lares application security team in the full session recording. Enjoy!
Watch The Session
Mark Arnold has a 15+ cybersecurity career, serving 8 of those years in leadership roles. As a transformational leader, Mark has built security teams and programs, authored maturity model blueprints to optimize risk management processes, and implemented security domain practices at large enterprises and service providers. Mark’s areas of interest include cloud security, threat intelligence, and vulnerability research, nation-state attack methods and related activities (e.g. information operations and disinformation campaigns) and their collective impact on nations and society. Mark recently completed an executive education cohort on the intersection of cybersecurity and technology at Harvard’s Kennedy School.
