The 7 Hats of Hacking
Learn about the seven different hats of hacking and how they can benefit your organization.
Worried about penetration testing derailing your sprint cycles? Understanding timelines and best practices will help avoid this pain.
TL;DR:
Are you worried about penetration testing derailing your sprint cycles? Penetration testing can feel like a daunting task. Especially when you are unsure how long it will take, what’s expected from your vendor, and the feeling of being publicly evaluated in front of your team on a subject outside your expertise. Feeling worried that penetration testing will derail your sprint cycle? Having a good understanding of timelines, considerations, and security best practices will help avoid this pain.
It can be hard to pull resources from your development team for security when a large focus is meeting client commitments and pushing new features and updates at a consistent rate. Some development teams work with regimented sprint cycles and aren’t able to take on anything additional until they fully understand the amount of time, effort and resources required for security. Other teams may have more flexibility when it comes to security work. Lack of information available can lead to teams underestimating the efforts and rewards of penetration testing and often leave them with condensed timelines for audits, and overall anxiety for the developers and greater team.
To combat this, imagine if you considered security remediations and efforts as another feature you have to build. If you are doing business with enterprise clients or companies in healthcare, fintech, security or any government or regulated industry, your security is a feature that their team expects and is often built into the contract. Most development teams should aim to dedicate 2 - 4 hours of security work for each cycle, to reduce bottlenecks of security work distracting from other planned efforts.
To help prepare your team and plan for your next penetration test, let’s look at penetration test timelines and considerations.
These are the 2 most common scenarios in which you need to consider penetration test timelines:
If you are in scenario 1, being proactive with a penetration test will help you understand your real security risks for your organization and clients’ data, as well as help you prepare for future compliance endeavours.
If you are in scenario 2, it is important to take into consideration your audit timelines alongside your penetration testing efforts. Understanding the preparation and planning needed will help make your SOC journey smooth and efficient (potentially reducing more administrative controls).
Here is the typical breakdown of a penetration test.
In general, it is good practice to start to plan 2 months before your desired penetration test date. If you are completing your compliance journey, it is recommended to start 2.5 - 3 months before your audit start date.
This planning can include:
The scoping process to understand your full attack surface should take 1 - 2 hours maximum. This includes preparing your environment, providing URLs/IPs in scope, creating accounts (2 per role), and completing the pentest checklist that is provided 2 weeks before your testing date.
It’s best to plan for 2 - 6 weeks lead time to ensure a spot on your choice pentest vendor’s calendar. Once you have a date booked for your penetration test, you will begin onboarding.
A penetration test will generally take 2 - 4 weeks if your vendor is high quality, does the majority of testing via manual efforts, and writes custom test plans for the business logic of your application.
On the first day of penetration testing with Software Secured, you will attend a short kick-off meeting to provide a technical demo of the applications in scope, ensure account access has been provided and answer any questions you may have. This is also the time to verify or clarify any questions surrounding the pentest checklist. You will also get to meet the pentesters and join your Slack channel. This takes no longer than 1 hour.
During the test, you will only be contacted if a critical vulnerability is found, in which case, you will be notified as soon as possible. Other than that, unless there are any blocks to access or further information needed for increased testing coverage, you won’t be contacted until the test is completed.
After you receive your penetration test report, your remediation plan is dependent on a few factors, such as your service level agreements (SLAs) with your clients, within your Vulnerability Management Policy or those recommended by your pentesters, as well as your vulnerabilities’ severity, volume and overall risk tolerance. With Software Secured’s penetration testing clients, we offer a read-out report meeting to go over priorities, and steps to remediation, and answer any questions about delegating and accepting risk. This helps accelerate fixes for your team and serves as an awesome security education opportunity with the real code your team has written.
You need to solve any criticals within 2 weeks maximum of getting your report, it is ideal to plan 2 - 3 sprint cycles to close all criticals and highs and document your remediation plan in your risk registry which is required for SOC 2 and other compliance frameworks.
After your team has completed remediation efforts, you can request a re-test to confirm your vulnerabilities have been fixed. From request to retest, this can take an average of 48 hours if the vulnerability is critical, or up to 1 - 2 weeks depending on the vulnerability (severity, volume etc.) and your vendor’s testing schedule.
To align your penetration test to your sprint cycle, it is important to know what to expect from your vendor. This can include confirming scope, planning your penetration test well in advance of your audit dates or enterprise commitments, and prepping your developer schedules with ample time for pentest setup and remediation.
Watch 5 Scoping Questions You Need to Know Before a Penetration Test
Here is a sample of our scoping questionnaire before a penetration test with Software Secured.
Knowing what information will be required from your vendor to begin the pentest will save you a lot of time and effort. Download our Sample Penetration Test Pre-Assessment Checklist to understand what information your vendor might ask for before your penetration test.
Bonus Tip:
It is easier to do pentesting before a SOC 2 audit, instead of at the end of the audit with a lot of security work and change fatigue from closing SOC 2 controls. It also becomes easier to understand risk after seeing the report and connecting dots with SOC 2 controls and client security requirements. It is also strategic to do a penetration test first as it helps prioritize most sensitive data (such as client data in applications) and proves security maturity to your clients as you continue maturing your security program.
Here are some questions to help you evaluate your sprint cycle and security relationship.
Where can you make changes to integrate security into sprint cycles with more ease?
Many development teams that are aiming to shift left, have begun building in monthly or quarterly 4 - 8 hours of security effort. More is required around annual or quarterly penetration testing or SOC 2 audits such as monthly or quarterly vulnerability scanning, and monthly patching of VMs and or base containers/docker files/3rd party libraries to maintain security health.
Are there measures you can put in place to make penetration testing easier?
For example, you may be able to reduce scope with apps that are being sunset or no longer for sale, cleaning up tech debt, or internal use applications not available publicly. Doing this results in less attack surface and less pentest vulnerabilities that need remediation or a track record indicating business rationale for accepting that risk for your compliance auditor and clients.
Are you in a place where continuous pentesting makes more sense?
For fast-growing SaaS companies that want to integrate security into their development pipeline, Penetration Testing as a Service (PTaaS) might make the most sense for your team. There are various benefits when it comes to integrating penetration testing into your security program.
Quarterly comprehensive tests ensure new product features are secure before they hit production. Integrated testing allows for lower remediation costs, developer time saved, and reduces risks of vulnerabilities found in client-facing assets. This could lead to stiff financial penalties, client churn and data breaches.
Penetration testing will not derail your sprint cycle, if it is considered a part of it. Planning and preparation will reduce the anxiety and stress of condensed timelines and help build more security champions on your team. Don't be worried that penetration testing will derail your sprint cycle; instead, consider it a vital part of it. Evaluating and improving your sprint cycle and security relationship will help push features and updates more efficiently, without compromising security. Check out 4 Ways Security Leaders Uses Penetration Testing to Elevate Their Security Programs to learn how security leaders create efficiencies in their sprint cycles and security programs with penetration testing.
Security
Can be easily manipulated without detection if not properly secured.
Digitally signed and can be validated on the server. Manipulation can be detected.
Size
Limited to 4KB.
Can contain much more data, up to 8KB.
Dependency
Often used for session data on the server-side. The server needs to store the session map.
Contains all the necessary information in the token. Doesn’t need to store data on the server.
Storage Location
Browser cookie jar.
Local storage or client-side cookie.
No testing strategy is one-size-fits-all. Pentesting in a production environment can provide advantages, though it does come with many risks.
Providing the quality of the biggest names in security without the price tag and complications.
Manual penetration testing
Full time Canadian hackers
Remediation support