When in Doubt, Validation is the Key

March 22, 2017

I’ve been working in IT since 1994, and IT security since 1995, when I worked for a collection agency who performed ecommerce business-to-business transactions with health care entities. I considered myself a good network penetration tester. Up until not too long ago, if your system had an IP address and a weakness, I would find it and exploit it (missing patches, weak SNMP community strings, weak protocols (RIP, SMB, etc.) blank passwords, etc. on servers, routers, switches, printers, workstations, etc.).  

Within the last few years, network security has gotten stronger, so it is a lot harder to be successful just being a network penetration tester. I used to leave the application penetration testing up to more advanced testers. Recently I’ve started doing more application penetration testing.  It is much more difficult and time consuming to do application layer penetration tests. I recently read all of the material from OWASP[1] to prepare for taking the Offensive Security Certified Professional (OSCP)[2] test. It is not for the faint at heart. This is because there are a lot of ways to break into applications and there is a lot to memorize and be aware of. Just as there are many ways to break into applications, there are, of course, many ways to secure applications. In almost everything that I have read and worked with when it comes to weak applications, input validation and exception handling are two of the fundamental things that your developers can do to prevent a majority of the worst-case breach scenarios.

Validation is the key; not just validation within the application, but validation that your application development team has people on the team that understand how to code securely. Ask the leader of your application development team if they have members of the team that know what OWASP is. If they do not, then I would recommend getting them trained on some any secure coding best practice, such as NIST[3], Microsoft[4], etc.

When it comes to getting an outside vendor to do penetration testing, validate that they are conducting the penetration test that you need. For example, if they do not ask for credentials (admin, basic client, basic user, etc.) for the application, then most likely they are not doing a full application layer penetration test.  It may be just an automated or manual vulnerability assessment or network penetration test. A good penetration tester does manual testing with the credentials supplied by the client. The most successful penetration testers are creative and do a majority of their work using manual processes or custom developed tools. If you every wonder why there is such difference in pricing between a penetrating test and a vulnerability assessment, this may be one of the best indicators.  A true penetration test by skilled application security penetration testers takes much longer than vulnerability assessments or a network penetration test because of vast amounts of manual checks done and the additional quantity of things tested.

When it comes to your sensitive data, validate where your sensitive data is by asking the owners or custodians of the data if they know everywhere e sensitive data is transmitted, stored and/or processed. If they do not, then the next step is to conduct a project to find it. A follow-up question is asking what layered defenses are used to protect the data.  Examples could include;

  • Transit -encryption, data loss prevention, Web Application Firewall
  • Processing -anti-malware, up-to-date patches, secure configurationsStorage -  (encryption, file integrity monitoring, etc.)

It seems like almost every conversation we have; either between HBS security team members; or between HBS security team members and clients, someone on the security team says, “Trust but Verify.”  Verification is the key.  The top five validation questions to ask are:

  1. Do we know where our sensitive data is transmitted, stored and/or processed?

  2. Is our information technology architecture built with layered security defenses to protect sensitive data in transit, when it is processed, and where it is stored?

  3. Do our developers (whether internal or outsourced) use secure coding best practices to do their work?

  4. Do we validate that are applications are secure through regular testing (at least annually)?

  5. Do our penetration testers do both application and network based penetration testing – are they asking for credentials?


Title Text

Subtitle Text