Quais fatores determinam o escopo de um teste de penetração?

Asumiendo que entendemos por pentest una prueba de la capacidad de un intruso de sobrepasar las contramedidas y controles vigentes en un activo, los factores determinantes son: - Presupuesto: más dinero implica mejores pentesters o más diversos, o un alcance mayor. - Tiempo: si hay restricciones en el tiempo la efectividad del atacante se reduce, por lo que el alcance debería ser menor. - Criticidad del entorno: se dan casos donde hay entornos que podrían verse afectados por las pruebas. Lo que puede reducir alcances a través de exclusiones y excepciones. - Aprobaciones formales y escalados: entornos concretos, pueden necesitar aprobaciones. Esto puede excluir elementos del alcance. Me ciño estrictamente al pentest, en este caso.

Intelligence led security testing is becoming increasingly popular and for good reason. It provides a tailored approach to security testing and helps identify areas of vulnerability. I believe Intel teams and pentest teams should collaborate more on this.

Consider the following factors. - Budget - define what crown jewels asset to be in scope. - Engage related stakeholders - Remediation.

Scope is really a sign of maturity in most organizations. When people are just getting started, it's typically an external pentest with the objective to "hack us", or it's a compliance oriented assessment. As organizations mature their program they start to establish specific objectives like "bypass MFA on the authentication portal", or hone in on specific apps or start moving towards internal pentests, social engineering scenarios, facility assessments, supply chain assessments or exploitation of specific business processes. But ideally the risk profile of the organization and the scenarios that create the greatest risk for their critical functions is what should be driving the scope.

One of the most essential advice for anyone engaging in a penetration test is to act on the results. If you are having a penetration test run on your environment to say, "Yes, we had a penetration test," then you are doing yourself and your customers a disservice. When issues are identified, it is essential to act on those issues. And it is important to remember that there is usually more than one way to work on a finding. You could take direct action (depending on the issue, perhaps patch or change a firewall rule), but one must remember that compensating controls are also available. These are alternate methods to shore up security outside the direction of action, perhaps to buy time until funding is available.

Crafting the scope and boundaries of a penetration test is like delineating a controlled battlefield. You've got to pinpoint the systems, networks, and applications under scrutiny, setting clear limits and exclusions. It's not just about what's in; it's equally about what's out. Rules of engagement become your ethical compass, guiding the path between legality and efficacy. Whether you're delving into the innards of your internal network with a white-box approach or navigating the unknowns of your external terrain with a black-box strategy, understanding the methods and tools at your disposal is crucial. Think of it as defining the playground where security resilience gets stress-tested while ensuring you play by the ethical rulebook.

Nas análises de segurança da infraestrutura empresarial, a equipe de segurança define os sistemas a serem avaliados, estabelece regras de engajamento detalhadas e leva em consideração implicações legais e éticas. Geralmente, opta-se por uma abordagem de caixa branca na rede interna, com conhecimento total, e de caixa preta na rede externa, sem informações prévias. A precisão na delimitação do escopo contribui significativamente para uma avaliação mais eficaz, concentrando esforços na identificação de vulnerabilidades e na implementação de correções necessárias.

Defining scope and boundaries relative to pentest exercises helps define borderline areas and makes for a more effective and efficient method of managing cybersecurity risks. Organizations approaching pentest exercises from a blanket (borderless) perspective often miss the value of it. Defining scope and limiting boundaries makes it easier to iterate on progress and improvements over time. Although pentest scopes and boundaries are often determined by factors such as regulations and compliance obligations, organizations should leverage and adapt these methods to address business needs, learn, and continually improve rather than merely check boxes for compliance purposes.

Defining the scope and boundaries for a pentest engagements is a crucial step to ensure success of objectives and goals. Basic factor to do this step is to know your network and environment quite well to decide what’s exactly needed to discover more about it. Sometimes your country’s regulations will be the motive behind your project while some other times pushing your security bars out of their limits will be.

The benefits of a penetration test are the combination of findings to achieve an objective that demonstrates a larger risk. Demonstrating the larger risk may require the combination of low and medium rated findings that are associated with different systems. Limiting the scope of an attack and penetration test may give a false sense of security as those connections or combinations of findings may not be discovered. This can leave an organization open to unknown risk. I recommend increasing a scope versus limiting a scope of work. You do have to take into consideration, the skill of individuals performing the penetration test, and their ability to properly handle risk that would impact the business.

Determining appropriate methodology and tools is crucial for an effective pentest. Consider the steps and phases your pentest should include, the techniques and strategies to use, and the tools and resources required. Following standard methodologies like NIST SP 800-115 or PTES can be a strong starting point. Tailoring your approach based on your needs could be beneficial. The right balance of manual and automated tools, such as Nmap, Metasploit, or OWASP ZAP, enhances efficiency and effectiveness of the test.

A eficácia de um pentest depende da escolha adequada de metodologia e ferramentas. É crucial considerar as etapas, fases, técnicas e estratégias, usando equilíbrio entre ferramentas manuais e automatizadas como Nmap, Metasploit e OWASP ZAP. A metodologia padrão envolve planejamento, coleta de informações, análise de vulnerabilidades, exploração, pós-exploração e relatório. Ferramentas incluem Nmap, Nessus, Metasploit e Wireshark. O escopo do teste depende de orçamento e cronograma, sendo recomendado focar em ativos críticos e componentes essenciais para obter máximo benefício, especialmente em pequenas e médias empresas.

Penetration testing typically follows a structured methodology, often based on frameworks like OWASP or NIST. It involves: 1. Planning: Define goals, scope, and rules of engagement. 2. Information Gathering: Collect data about the target, like IP addresses or domain names. 3. Vulnerability Analysis: Identify weaknesses in systems, networks, or applications. 4. Exploitation: Attempt to exploit vulnerabilities to gain unauthorized access. 5. Post-Exploitation: Assess the extent of compromise and potential impacts. 6. Reporting: Document findings, risks, and recommendations for remediation. Tools include Nmap for network scanning, Nessus for vulnerability assessment, Metasploit for exploitation, and Wireshark for packet analysis.

Of course tools are important, but every process needs a methodology and the knowledge to make it work. Pentest is no different, knowing the basis of programming, operational systems and networking, a pentester will find much more vulnerabilities than only running tools randomly. The recon step is also very underrated.

To carry out pentest activity steps and phases that will be considered are given below 1) Black, white and Grey box pentesting should be considered i.e when carry out for public network black box testing should be first approached, for internal and new application & its underlying infra which are going to deployed in public domain should be first checked as white box approach by internal team or should be outsourced to pentesting & Grey Box approach should be considered when application is deployed need to validated by external parties or regular basis so that new & undiscovered issued will be identified As far as tools are concerned combination of mix tools e.g. opensource and commercials should be used along with customize scripts

O escopo de um teste de penetração depende do momento e orçamento disponíveis, sendo essencial maximizar o valor, especialmente para PMEs, através de testes de caixa branca e foco em ativos críticos. Ao considerar a criticidade do pentest na identificação de vulnerabilidades, é crucial definir prazos e custos realistas, alinhando-os com as necessidades da organização e evitando prazos irreais que possam comprometer a eficácia. O equilíbrio entre frequência, custo e eficácia é vital para uma postura de segurança robusta sem exceder o orçamento disponível.

A pentest timeline and cost are determined by many factors; however, the main driver should be the test objectives. The test objectives help us define the test scope, methodology, team skills, and constraints; hence, the ability to decide how long the test should take (and subsequently, how much it will cost). For example, a test that is supposed to simulate a determined highly skilled attacker will probably require more time and budget than a test that is performed to satisfy a relaxed compliance mandate. It is also important to prioritize our need for such tests against other cyber program needs; for example, if we still do not have the most basic controls in place, it'd make more sense to spend money on this rather than testing.

Ultimately, the scope of a penetration test will come down to when it needs to be done and what you can afford. Ideally, your budget and timeline allow for all assets to be thoroughly tested, however that's not always the case. With SMBs, in particular, the goal should be to get the biggest bang for your buck. In these instances white box tests are your friend. By lifting the hood to the testers and showing them how everything works, they can be much more efficient in their testing. Target critical assets, and scope the most business critical components. That's the best way to get value from a penetration test when you have a constrained budget.

Since pentesting is very critical process to identify vulnerability it is expected the right timelines are defined basis on complexities of pages e.g. dynamic or static pages data bases, web servers are involved and for infrastructure are how many servers are there and level of pentesting required along with the SME/s(subject matter expert/s) involved basis on that man hours should be calculated i.e costing(price), along with timeline which is aligned with Organization need and should not unrealistic as it will impact the pentest and vulnerabilities will remain undiscovered

Timing and budgeting in the realm of penetration testing are like plotting a course through both time and finance landscapes. Considerations of how long the test will unfold and how much it'll cost weave into a delicate tapestry. Are you opting for an annual checkup or aligning tests with system overhauls? Balancing frequency against constraints is key. The price tag encompasses not just external pentesters but also the tools, licenses, and internal resources. It's a financial ballet, factoring in the cost of fortifying digital defenses against potential threats. Striking the right balance ensures a robust security posture without breaking the bank.

Reporting is one of the most important outcome of Pentest which should address the concern of every stack holder includes in pentest activity i.e from C Suite, manager to development team. Hence report should include high level summary along with the numbers which are required Top level reader of that report and also it contains detailed observation steps along with right PoC highlighting how those observations during pentest identified along with the remediation timelines by which vulnerability discovered should be remediated by concern stakeholders, So that Pentest revalidation can be initiated and risk associated with those vulnerabilities should be reduced

Findings have to be risk-based. All too often, pen-testers specify the non-contextualised default gross risk level. However, in the context of the system and environment, the actual risk may be lower, or higher. Therefore, the pen-tester needs to partner with the infra/app custodians to determine the actual risk rating. A good pen-test contextualises the risk and does not simply fixate a default risk rating to a specific technical finding. For instance, a session cookie that is leaked through cookie testing during pre-authentication and verified that it is not used as post-authentication session cookie should not be treated at the same risk levels.

I have seen reporting requirements covering 3 aspects. First, a management summary to give a lucid view of the identified vulnerabilities and utilized TTPs. Second, should be a detailed report covering detailed remediation steps against the identified vulnerabilities. And lastly, risk based input to the organizational risk management tool for governance

The report must cover all the scope, methodology, results, and recommendations of the pentest and cater to both technical teams and executives mainly towards taking decisive action. Report must list out all vulnerabilities based on criticality - risk level and impact level in detail so that there are clear actionable steps that can be taken to remediate and address the vulnerabilities starting from the ones that have critical impact to comparatively lower. Recomendations must include clear direction towards involve patching software, changing configurations, or updating security policies.

Wrapping up a penetration test is not just about findings but about crafting a roadmap for fortification. How you document and communicate the vulnerabilities uncovered is akin to telling a story, one that guides actions for a more secure future. Whether you opt for a detailed saga or a succinct battle plan, the report should be a blueprint for action. It's not just about spotting weaknesses; it's about orchestrating the fix. Prioritizing, assigning responsibilities, and setting deadlines turn discoveries into resilient safeguards. It's the post-test dance, where every step is a move toward a more fortified digital terrain, ensuring that vulnerabilities uncovered are swiftly transformed into strengths.

This portion can be challenging because stakeholders have different expectations of what the outcome of the penetration test should provide depending on their perspective roles. An IT engineer is going to want knowledge of different details to understand the issue than the CISO.

Managing the expectations of different stakeholders is important to ensure successful closure of the test. For this to be successful, it should ideally start as early as possible in the planning phase. It starts by identifying relevant stakeholders and their expectations, then aligning the test with those expectations (or vice versa, when stakeholders expectations are not reasonable). For example, some stakeholders may be under the impression that a penetration test that generates no major findings means the system is not hackable, not understanding the fact that such tests only provide point in time picture, and are limited by the time spent on them (vs. a determined attacker, who may spend months trying to penetrate the service).

Na minha experiência profissional, o alinhamento de expectativas com os stakeholders sempre foi fator chave de sucesso para os pentests. É fundamental compreender as expectativas do negócio com a realização de um pentest, mas também fornecer informações relevantes que podem tornar o resultado do pentest um valor agregado e diferencial competitivo, que atesta na prática o nível de maturidade dos processos e controles de segurança da informação.

Stakeholders and their expectations are the center of security testing as they need to know and act on findings. It’s essential to align the stakeholders expectations which will drive the success of penetration testing by providing clarity on weaknesses to stakeholders which can help them to prioritise the actions based on criticality.

One of the most important points in determine the scope of the Penetration testing is to have full understanding of the Business flow behind. By understanding the business flow/business needs you will be able to create the right threat modeling which will support to put the right test cases . Again, you shouldn't be focussed only on the technical part. You must understand the business flow .

The scope of a penetration test is shaped by its objectives, the range and type of target systems, and the depth of testing required, considering the client's risk tolerance and potential impact on operations. Budgetary constraints, time limitations, compliance with regulatory requirements, and the need for specific reporting also play significant roles in defining the test's extent. Additionally, previous test findings, stakeholder expectations, and legal and ethical considerations are crucial in determining the approach and focus areas of the penetration test.

Also consider a live execution session in the end in which the penetrated show your engineering teams how they exploited the high and / or very high vulnerabilities they could find. That way you ensure awareness, provide training but also add a gamification component that drives engineers to think more critically and do better next time.

Na segurança da informação, o teste de violação do ambiente (Pentest) deve ser algo rotineiro, de preferência já previsto e pré-aprovado no orçamento do departamento, visto que, com as constantes mudanças do ambiente tecnológico novos riscos e vulnerabilidades surgem constantemente. Desta forma, a busca por brechas, sejam elas falhas de configuração, falhas nas soluções tecnológicas ou ainda desvios de comportamento nas pessoas expostas a golpes de engenharia social, devem ser inspecionadas e testadas recorrentemente. Cada modelo de teste tem seus pontos forte e fracos sendo que para bom resultado num projeto de pentest é importante adaptar a abordagem do teste de penetração às necessidades e características exclusivas da empresa.

Wesentlich ist, den Umfang der Penetration-Tests vertraglich festzulegen: bestimmen Sie die Prüf-Objekte, die betreffende Institution, die eingesetzten Tools und den zeitlichen und technischen Prüfungsumfang. Ebenso sollte vereinbart werden, welche Qualifikation die Prüfer vorzuweisen haben und wie sich der Prüfungsablauf und die dazu notwendigen Vorbereitungen oder Mitwirkungshandlungen darstellen. Schließlich sollte klargestellt werden, in welche Weise der Test und sein Ergebnis dokumentiert wird.