Do you have an application that was developed to purchased and you’re wrestling with whether to pay for it to be security tested or not?
So when should you penetration test an application? You should pen test an application if it exceeds your risk threshold. Often this is when it contains sensitive or confidential data if it is under regulatory compliance requirements, or it is externally facing, or it connects to other critical systems within your network.
Deciding if an application exceeds your risk can be determined by leveraging a risk register.
What is a Risk Register?
To make these decisions easier and more efficient it’s best to create a policy statement to dictate at what risk level, or under what circumstances an application should be pen tested. Then create a document that lists and records the applications. In this document list all the qualifications that drive the classification and risk of the application. Qualifications include the same topics we’re reviewing in this document.
You can assign a point system to each qualification and track the total overall score of each application. You can also use a scoring system to create data classification thresholds.
For example, your policy may state that applications that are risk ranked ‘confidential’ require a pen test. If the application contains PII data add 10 points. If the application contains SSN add ten points. If the application is under SOX regulation add 30 points. Not only will this document make it easier to make penetration testing decisions but it will also provide an evidence document to regulators and evidence to incident investigators in the event you are breached. Even though this not something we want, if it does happen you want to be able to show and prove you exercised diligence in the review and application of appropriate controls.
Below are criteria to consider for your risk register, or indecently to fuel your decision on whether to penetration test the application.
Does the application contain sensitive or confidential data?
Although we want to comply to laws and best practices, or fundamental motivation as security practitioners are to secure data that should remain private form the hands of those that would hand it over and give it to the dark web sales genie. Preventing your sisters SSN from being sold for $4 is the business we’re in.
Consider the classification of the data the web application will query, store, or transmit. If any data classified beyond your companies security policy allows, then you should verify the security controls within the application with a pen test. Often this is data that is classified as sensitive or confidential.
If your company doesn’t have a statement in the information security policy that dictates what needs to be assessed or doesn’t have a data classification matrix for data than you should use your best judgment. Does the data contain a value that is worth an external attacker to capture, change, manipulate, sell, or destroy? Usually, a quick heart check can reveal the value of this data.
Internal or Outside Resources?
Penetration testing an application can be expensive but doesn’t have to be. Often times the companies we work don’t have this type of security expertise internally. They have to outsource it to a company that specializes in penetration testing. But even companies that I have worked with that do have full-time resources dedicated to pen testing still have to consider this carefully. I’ve seen pen test ques grow out of available resources. Testing an application appropriately takes times and resources. and not matter if you offer this internally or have to outsource it this question should be carefully considered.
Is the application externally facing?
If the application is externally facing that means the whole world has access to it, whether privileged access or not, it is available to beat on an attempt to gain access to. The external availability of an application significantly changes the risk of an application. This availability can drive review of the security of the application. The only exception to this is it is a static application that doesn’t connect to anything and provides stale data. But if it’s externally facing and also provides some type of data connection, you should consider it for review.
Does the application allow connection to other resources?
Sometimes the front end application doesn’t present any significant risk, but it connects to a back-end data repository that queries, pulls, or puts data. If this is the case then there is a data integrity and availability issue that should be reviewed for security. You want to prevent a malicious vector to change, corrupt, or remove availability to data.
Often these connections are made to back-end databases with service credentials. That means that if the front end application is popped, the back-end data repository is popped and all data is owned by the attacker.
Is the application is considered in scope for compliance regulations?
Sometimes you have rules to follow. Sometimes these rules are regulatory requirements. Often these requirements will not come out and state you need to have the application penetration tested, but they will state something like ‘considerable effort has been performed to secure the application’. The best way to confidently check this box with by performing a penetration test.
You’ll have to look at the individual regulatory compliance requirements including PCI, and SOX and other requirements your company falls under to determine the individual requirements and data for testing the application.
What should a penetration test include for testing?
An application penetration test focuses on coding best practices. It looks for vectors of exploitation of today’s attackers. The best framework, or documented attack vectors, for this approach, is OWASP. There are a ton of attack vectors and OWASP does a great job attempting to document and explain them all. Here is their resource on attacks:
https://www.owasp.org/index.php/Category:Attack
To start you should focus on the OWASP Top Ten. This is a list of the ten most popular and prolific attack vectors. Your security review should start here:
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
Our Services
At Asher Security, we help small and medium companies reduce their risk by helping them create cybersecurity programs. We focus on consulting and workshops that help drive return on risk for businesses. We only focus on what we’re great at.
Penetration testing is not something we’re focused on. We’ve published this article as part of our philosophy and approach to help educate businesses about the risks of cybersecurity.
We do partner with a couple of Minnesota companies that do specialize in penetration testing. We trust them and can vouch for them. We have listed them below for your benefit. If you want a personal connection, reach out to us and we can schedule a call or meeting to introduce you to them.
Summary
Penetration testing is a great practice to implement but should be implemented only on applications that meet certain risk classifications either outlined by your security policy, data classification matrix, or best attempts for determination.
Penetration testing can cost a significant amount of money but still remains one of the lesser priced information security services offered by external consultants. The return on investment is huge when considering the impact a compromised application can have on business and the clients perspective of the companies reputation.
By using a standardized decision approach to penetration testing you can justify the spend and prove due diligence to external parties if the case presents itself.
Recent Comments