Your #engineers should be able to read a penetration testing finding and understand what needs to change. The report identifies a weakness, assigns a severity rating and includes a screenshot. The recommendation says: "Implement appropriate security controls." The #development #team now needs to interpret the issue, identify the affected component and determine what a successful fix would achieve. How much of that work does the report support? A useful finding should connect: - The affected functionality, - The relevant conditions and assumptions, - The behavior observed during testing, - The evidence supporting the stated impact, - The corrective action being recommended. The #report should also distinguish demonstrated results from broader consequences that remain conditional or unverified. This is one reason technical review matters before delivery. Does the evidence support the conclusion? Is the impact described accurately? Does the recommendation address the identified weakness? Are limitations visible? #Quality #assurance should examine those questions as well as clarity and consistency across the report. At #Logisek, report quality is part of assessment quality. The deliverable needs to serve the people making remediation decisions, implementing changes and explaining the risk internally. When evaluating a #penetration #testing provider, ask to review an appropriately sanitized reporting example. Can your engineers understand it? Can your security team assess the reasoning? Can management understand the business relevance? A strong report gives each audience enough information to make the decisions expected of them. - logisek.com #OffensiveSecurity #PenetrationTesting #QualityAssurance #Cybersecurity #Offsec #Logisek

A red team engagement is being proposed. What should your organization know when it finishes? Your organization has endpoint protection, centralized logging, identity controls and a team responsible for investigating suspicious activity. The proposal describes a realistic adversary simulation. Before the engagement begins, the objectives need to be clear. Which business concern is the exercise intended to assess? What starting access is assumed? Which systems and activities are authorized? How will the outcome be evaluated? These decisions shape the meaning of the results. An exercise starting from an assumed internal foothold answers different questions from an exercise that includes assessing external access. Both can be valuable when the starting conditions match the agreed objectives. Where detection and response are in scope, the organization should also understand: - Which relevant activity was recorded, - Which activity generated alerts, - What information reached the defenders, - How investigation and escalation developed, - What the evidence suggests should improve. An absence of visible response does not, by itself, establish that no detection occurred. The conclusion requires supporting evidence and appropriate discussion with the defensive team. The technical and defensive observations need to be brought together during the debrief. That is how an exercise can produce a practical understanding of demonstrated capabilities and remaining gaps. Before selecting a #RedTeam provider, ask how it will connect its observations to your objectives. A useful engagement should leave your organization able to explain what it learned and which changes deserve attention next. - logisek.com #OffensiveSecurity #RedTeam #Cybersecurity #DetectionAndResponse #Offsec #Logisek

Two vulnerabilities have the same severity rating. Should they receive the same remediation priority? Your team receives a #penetration #testing report. Several findings are rated High. They affect different systems, require different conditions and have different consequences for the business. The engineering team needs to decide what to address first. A severity rating provides useful information. Prioritization also requires context. Relevant considerations may include: - The exposure of the affected system, - The access required for the issue to occur, - The sensitivity of the information involved, - The importance of the affected business function, - Existing controls that influence the risk, - Dependencies and practical remediation options. These factors should be discussed with the people who understand the environment. A report should explain the reasoning behind its ratings and distinguish observed impact from possible consequences that were not validated. It should also make clear where important business context remains uncertain. Without that explanation, a severity label can become difficult to interpret or defend. The client may spend time debating the number while the underlying security decision remains unresolved. Useful reporting gives security, engineering and management teams a common basis for that discussion. Before choosing a #provider, ask how it connects technical severity with the environment being assessed. Will the findings explain the conditions, affected assets and business relevance? A remediation priority should be understandable to the people responsible for acting on it. The report should help them reach that understanding. - logisek.com #OffensiveSecurity #PenetrationTesting #RiskManagement #VulnerabilityManagement #Offsec #Logisek

Your latest penetration test identified fewer vulnerabilities than the previous one. Is that a good result? Possibly. But the number alone cannot explain what happened. The application may have improved. The scope may have changed. The available accounts may have been different. Several related issues may have been consolidated into one finding. The assessment may also have faced limitations that affected coverage. The same caution applies when a report contains many findings. A high count does not, by itself, establish testing depth or business impact. Consider the questions behind the number: - Were the same systems and versions assessed? - Was comparable access available? - Were findings grouped consistently? - Did the assessments have similar objectives and effort? - What evidence supports the reported impact? - Which areas remained untested? These details matter when comparing results across engagements or providers. A single well-supported finding affecting an important business process may require significant attention. Several lower-severity findings may also matter, particularly where they reflect a recurring control problem. The value of the work depends on what the assessment establishes and how it helps the organization respond. For clients, a more useful discussion examines coverage, evidence, relevance and the practical value of the recommendations. Those are areas where a provider should be able to explain its work clearly. Before asking whether a penetration test found enough vulnerabilities, ask whether the results give you a defensible understanding of the assessed risk. - logisek.com #OffensiveSecurity #PenetrationTesting #VulnerabilityManagement #Cybersecurity #Offsec #Logisek

Your #application runs in the cloud. Which security controls are actually being assessed? The environment includes managed databases, cloud storage, application services, service identities and several integrations. The cloud provider operates parts of the underlying platform. Your organization configures and uses the services. The exact division of responsibility depends on the service, but the assessment still needs a clear understanding of the controls relevant to your deployment. A penetration test against the public application may provide valuable evidence about that application. It may leave other important questions unanswered. For example: - How are permissions assigned to users and service identities? - Which storage resources are accessible, and to whom? - How are development and production environments separated? - How are secrets handled? - Which security events are available for investigation? Some questions are best addressed through application testing. Others may require an agreed configuration review, architecture review or a combination of assessment methods. That should be discussed before the scope is finalized. #Cloud #security #assessment is a broad description. Clients should understand the accounts, subscriptions, projects, services and control areas included in the work. They should also understand what access the assessors need and how missing access will affect coverage. At #Logisek, these are important questions to bring into the scoping discussion. The #assessment method should fit the security question you need answered and the controls your organization actually manages. - logisek.com - Logisek #OffensiveSecurity #PenetrationTesting #CloudSecurity #Cybersecurity #Offsec #Logisek

An infrastructure assessment should help you understand how your environment is connected. Your organization has: - Employee workstations, - Business application servers, - Centralized identity services, - Administrative systems, - Separate network segments, - External access provided to selected partners. An assessment identifies several vulnerabilities and configuration weaknesses. The next question is what those findings mean within that environment. Which systems support critical operations? Where are privileged accounts used? Which network boundaries are intended to restrict access? What assumptions exist about trusted devices and users? A weakness on an isolated test system may have different consequences from the same weakness on a system supporting an important business service. Similarly, the significance of a configuration issue can depend on the access it provides and the controls surrounding it. Meaningful #infrastructure #penetration #testing requires enough context to assess these relationships within the authorized scope. Before the engagement, discuss: - The starting access assumed for the assessment, - The identities and systems included, - The segmentation boundaries that matter, - The business services requiring particular attention, - The limitations on validating potential impact. The report should distinguish relationships demonstrated during testing from those inferred or left unassessed. That distinction allows the client to understand both the evidence and the remaining uncertainty. An asset list is useful for defining scope. Understanding the environment also requires examining relevant connections between those assets. Can your assessment explain how the identified weaknesses affect the security boundaries your organization relies on? - logisek.com #OffensiveSecurity #PenetrationTesting #InfrastructureSecurity #Cybersecurity #Offsec #Logisek

An application can authenticate every user correctly and still expose information to the wrong people. You are planning a grey-box #web application penetration test. The application includes: - Several user roles, - Multiple customer organizations, - Administrative and support functions, - Records owned by different users, - Workflows involving different levels of approval. The login process works correctly. Multi-factor authentication is enabled. Sessions expire as expected. Those are important controls. But they answer only part of the security question. #Authentication establishes who a user is. #Authorization determines what that user is allowed to access, change or approve. Meaningful authorization testing requires an understanding of the relationships between users, roles, organizations, records and business functions. Two users with the same role may still require complete separation because they belong to different customers. A support account may legitimately access certain information while remaining restricted from changing business-critical settings. A user’s permissions may also change as a transaction moves through different stages. These relationships need to be reflected in the assessment. Before testing begins, it is worth asking: - Which roles and account relationships will be available? - Are customer and organizational boundaries included? - Have the expected permissions been documented? - Will important business workflows be accessible? - How will gaps in access affect the conclusions? An assessment performed with one account may provide useful findings. Its conclusions must reflect the access and relationships actually examined. When you read the final report, can you understand which authorization boundaries were assessed? "Authenticated testing" should come with a clear explanation of whose access was tested, against which boundaries, and with what limitations. - logisek.com #OffensiveSecurity #PenetrationTesting #ApplicationSecurity #Cybersecurity #Offsec #Logisek

A business process can behave exactly as implemented and still create a security problem. Consider an application that manages purchasing, approvals, refunds or customer onboarding. The application may use current software components, validate common input formats and protect its communications correctly. But who defines whether the business process itself is secure? That question becomes important when the application includes: - Different levels of approval, - Transaction limits, - Changes in account status, - Several stages in a workflow, - Actions that should require independent authorization. #BusinessLogic testing requires an understanding of what the application is supposed to allow and which conditions must remain true throughout a process. For example, a sensitive business action may require approval from a different authorized person. The security requirement extends beyond whether both accounts can log in successfully. The assessment needs to consider whether the application consistently maintains the intended separation of responsibilities. Tools can support the work, but meaningful interpretation requires knowledge of the business rules. That knowledge often comes from discussions with application owners, developers and the people who use the system. Before commissioning an application #penetration #test, ask: - Will the assessment include a walkthrough of important workflows? - Who can explain the expected business rules? - Which actions carry financial or operational consequences? - How will the testing approach account for those consequences? At Logisek, understanding an application’s intended behavior is part of understanding its security. A technically valid transaction can still be an unauthorized business action. The assessment needs enough context to recognize the difference. - logisek.com #OffensiveSecurity #PenetrationTesting #BusinessLogic #ApplicationSecurity #Offsec #Logisek

One #compromised workstation. How far could an attacker go? At #Logisek, our assumed breach assessments test whether an initial foothold can lead to elevated privileges, lateral movement, and access to critical systems or sensitive data. Your internal controls should limit the impact of a compromise. Put them to the test. - logisek.com #AssumedBreach #OffensiveSecurity #RedTeam

October marks European Cybersecurity Month, and it is a good reminder that the cybersecurity landscape is changing just as quickly as the technologies businesses depend on. Artificial intelligence is already reshaping cybersecurity on both sides. It enables faster detection and analysis of suspicious activity, but it also gives attackers new ways to automate social engineering, generate convincing deepfakes and scale attacks more efficiently. At the same time, software supply-chain risk continues to grow. Organizations increasingly rely on third-party software, APIs and interconnected suppliers, meaning that weaknesses outside the traditional perimeter can have a direct impact on security. Looking further ahead, quantum computing is also becoming part of the cybersecurity conversation. While practical large-scale quantum attacks are not an immediate reality, organizations need to start considering long-term cryptographic resilience and the transition towards post-quantum cryptography. Geopolitical developments add another layer of complexity, particularly for organizations operating critical infrastructure and essential services, where cyber resilience, business continuity and incident response are closely connected. Cybersecurity is no longer only about defending individual systems. It is about continuously adapting to an environment where technology, supply chains and threat actors are evolving at the same time. - @netweek_gr #NetFax - logisek.com #Cybersecurity #EuropeanCybersecurityMonth #ArtificialIntelligence #SupplyChainSecurity #CyberResilience #QuantumComputing #Logisek

#Cybersecurity incidents often start with a simple email, message or phone call. A recent #ENISA survey found that 74% of employees had received suspicious communications, while 39% reported phishing attempts. At the same time, 85% said they would like to improve their cybersecurity skills. The message is clear: technology alone is not enough. Strong cyber resilience also depends on continuous awareness, practical training and employees who know how to recognize and respond to threats. - @netweek_gr #NetFax - logisek.com #SecurityAwareness #Phishing #CyberResilience #EuropeanCybersecurityMonth #Logisek

Cybercrime is borderless, and effective disruption increasingly depends on international cooperation. The Hellenic Police Cybercrime Directorate participated in the international "KillSwitch" operation, which targeted the KillSec cybercrime group. The coordinated action resulted in arrests and searches across multiple countries, the seizure of infrastructure and encrypted data, and the disruption of systems used to support extortion activity. The case highlights an important aspect of modern cyber defence: addressing organized cybercrime requires not only strong technical capabilities, but also cross-border coordination, intelligence sharing and coordinated law-enforcement action. - @netweek_gr #NetFax - logisek.com - @logisekict #Cybersecurity #Cybercrime #CyberResilience #InternationalCooperation #EuropeanCybersecurityMonth #Logisek

What happens when an #application is not ready for its scheduled penetration test? The scope and estimated testing effort have been agreed. The engagement has a planned start date, an end date and a report delivery date. When the work begins, however: - The environment is unavailable or unstable, - Required accounts cannot access the functionality in scope, - Application errors prevent important workflows from completing, - A necessary service or integration is not functioning. Testing cannot proceed as planned. What happens to the agreed coverage and the reserved testing window? At #Logisek, we inform the client promptly. We explain what is preventing progress, which parts of the assessment are affected and what needs attention. We also help with troubleshooting where needed, working with the client and the relevant technical teams so that meaningful testing can proceed. The distinction between estimated testing effort and elapsed calendar time matters here. A period during which the environment cannot be tested does not provide the coverage that the agreed testing effort was intended to deliver. Crucially, when these blockers prevent completion of the agreed work, we coordinate with the client to move or extend the predefined testing window. The reporting schedule is adjusted accordingly. We do not treat the original booking as a "use it or lose it" opportunity. Affected functionality is not quietly skipped, and the engagement is not considered complete simply because the original end date has arrived. The client should understand what remains to be tested, what needs to be resolved and how the revised schedule supports completion of the agreed scope. Readiness matters. So does the way a testing partner responds when the project encounters difficulties. Our priority is to complete a suitable #assessment across the agreed scope and give the client useful, well-supported results. A schedule should help organize the work. Reaching its original end date does not establish that the work has been completed. - logisek.com #OffensiveSecurity #PenetrationTesting #ApplicationSecurity #Cybersecurity #Offsec #Logisek

You are planning a grey-box #web or a #mobile application penetration test for a new application, or a major new version introducing new features and changes across the application. The application has: - 200+ API endpoints, - Potentially twice as many web forms, functions and user interactions, - Mobile application available on both Android and iOS, requiring platform-specific testing of the application itself, not only the backend APIs, - Multiple roles, workflows, authorization paths and business processes. The proposed effort is 5-7 days. If the agreed scope is a full end-to-end penetration test of the new application or the new version as a whole, that level of effort is simply not sufficient to provide meaningful coverage across an application of this size and complexity. And that should raise an important #question: What level of end-to-end coverage can realistically be achieved in 5-7 days? Meaningful application penetration testing is not simply about running tools against 200 endpoints. It means understanding #authentication and #authorization models, testing different #roles, exercising #business #workflows, validating #API functionality, exploring #abuse cases, testing input and file-handling mechanisms, and looking for ways individual weaknesses can be combined into realistic #attack #paths. This becomes even more important when assessing a new application or a major release, where new features, modified workflows and changes across different application components can introduce new security assumptions and attack paths. There is always a balance between time, budget, depth and coverage. The important thing is to understand that balance before the assessment starts. A penetration test should not only #answer: "Were vulnerabilities found?" It should also #answer: "How much of the application was actually tested, and how deeply?" So before choosing a #provider, it is worth asking: - Did you actually discuss the testing approach, methodology, scope and expected coverage? - Or did the decision ultimately come down to who offered the lowest price? Because completing a penetration test and achieving meaningful end-to-end #security #assurance are not necessarily the same thing. - logisek.com #OffensiveSecurity #RedTeam #PenetrationTesting #Cybersecurity #Offsec #Logisek

Not every #security test answers the same question. - A Vulnerability Assessment asks: What is vulnerable? - A Penetration Test asks: Can it actually be exploited? - An Assumed Breach exercise asks: If an attacker is already inside, how far can they go? - A Red Team or #Cyber #Adversary Simulation asks something bigger: Can the organisation prevent, detect and respond to a realistic attack before the objective is reached? That distinction matters. The NCSC’s Cyber Adversary Simulation (CyAS) scheme is another sign that offensive security is moving beyond finding vulnerabilities in isolation. The focus is increasingly on attack paths, realistic adversary behaviour and, ultimately, whether the defences work when they are actually tested. Finding #vulnerabilities is important. Finding out what happens when someone tries to use them is a different level of assurance. - logisek.com #OffensiveSecurity #RedTeam #PenetrationTesting #Cybersecurity #Offsec #Logisek

How secure are we? It is the only question the board actually asks. It is the one thing the security team is genuinely accountable for. And it is almost always answered with a slide somebody built by hand the week before. As an industry we are genuinely excellent at producing this evidence. Offensive security has never been better: better testers, better tooling, better reports, better standards. And we are collectively terrible at holding it. It is generated at considerable expense and allowed to dissolve into PDFs, tickets and spreadsheets within a fortnight. So the gap in most security programmes is not a testing gap. Buying another assessment will not close it. It is an evidence gap, it sits on the client side of every engagement, and that is why no vendor has ever fixed it for anyone. Closing it needs less than people assume. Somewhere that holds the estate, the assessments, the findings and the ownership as one connected thing, not four. A posture number built only from what was observed, never from what was asserted. Weightings you set yourself, so it survives an auditor asking why it says what it says. History retained, so improvement is provable. And the whole thing answerable on demand rather than assembled by hand the week before the board. None of that is exotic. It is bookkeeping applied to security evidence, roughly what finance did to money four hundred years ago and has not regretted since. The spreadsheet was never really the problem. It was the last honest signal that the problem had not been solved. - logisek.com #Cybersecurity #OffensiveSecurity #Offsec #PenetrationTesting #PenTest #Redteam #VulnerabilityManagement #CISO #CORTUS #Logisek

#Security Is Not Bought. It Is Proven. #Modern organisations invest heavily in firewalls, EDR, SIEM, identity platforms, cloud security and other security technologies. But an expensive security stack does not automatically make an organisation secure. The real value of any security control depends on how it has been designed, configured, integrated and tested against realistic attack scenarios. Default settings, operational exceptions, weak hardening and architectural gaps can significantly reduce the effectiveness of even advanced technologies. A recent #engagement demonstrated this clearly. An IT Director had invested in multiple security solutions implemented by different providers. On paper, the organisation had several layers of protection. In practice, a number of platforms were still operating with default or insufficiently hardened configurations, and the overall security architecture had never been assessed as a complete system. During a #RedTeam assessment, our team was able to bypass several controls and progress through multiple attack paths. The issue was not that the technologies were ineffective, but that they had not been sufficiently adapted to the organisation’s actual environment, processes and threat landscape. Rather than recommending another product, we focused on improving what was already in place through Security Configuration Reviews, Security Architecture Assessment and targeted hardening. The sequence matters. Configuration Audits should first establish the real state of the environment and identify weaknesses. Penetration Testing and Red Teaming can then validate whether those weaknesses have actually been addressed and whether remaining attack paths can still be exploited. This is where offensive security creates real value. It helps answer the questions that matter: Which controls actually work? Which can be bypassed? Which attack paths remain open? Where should the next security investment be made? For an #IT Director, the objective should not be to own more tools, but to know how effectively existing controls reduce risk. #Offensive security turns assumptions into evidence. It helps reduce wasted budget, improve the value of existing technologies and provide management with a clearer view of organisational resilience. The organisations that will be better prepared are not necessarily those with the most security tools, but those that can demonstrate that their controls work when they are actually needed. - Read the whole article here: infocom.gr/2026/09/21/i-asfa… - The Leaders of Digital Transformation: infocom.gr/2026/09/21/oi-pro… - logisek.com #Cybersecurity #OffensiveSecurity #Offsec #PenetrationTesting #PenTest #Redteam #VulnerabilityManagement #CISO #CORTUS #Logisek

Nothing in #security disappears as cleanly as an accepted risk. Not ignored. Not forgotten. Accepted, properly, in a meeting, by someone with the authority to accept it. Written down. And then never looked at again. Two mechanisms exist in most organisations for making a finding stop demanding attention. Both are legitimate. Both leak. The first is the #remediation #deadline. #Critical within so many days, #High within so many more, and so on down. Almost every organisation has this written into a #policy. Far fewer measure against it continuously, and the reason is mundane: measuring it requires knowing, for every open finding, its severity, its discovery date, its owner and its target, in one place, today. That is a query, not a document, and the policy is a document. So the deadline becomes something reviewed quarterly at best, which means findings breach in silence and are noticed weeks later, and nobody is ever warned that something is about to breach. That last part is the real loss. A finding three days from its deadline is actionable. A finding forty days past it is a conversation about why nobody noticed. The second mechanism is #risk #acceptance, and it is more interesting because it is genuinely correct practice. Not everything should be fixed. Some things cost more to fix than they could ever cost you. Deciding that deliberately, and recording it, is a sign of a mature programme. What is not mature is what happens next. The acceptance is recorded as a status change and a sentence of justification. It has no expiry. It has no review date. Frequently it names no individual, only "management" or "the business". And then the world moves. The system becomes internet-facing. The data classification changes. A new regulation lands. The compensating control that made the acceptance reasonable gets decommissioned by a team that never knew it was compensating for anything. The acceptance survives all of it, because nothing is watching it. Risk that was consciously accepted under conditions that no longer exist is indistinguishable, in the tracker, from risk that is still fine. We have re-tested systems where the most serious issue we found had been formally accepted years earlier, under circumstances that had long since changed. - logisek.com #Cybersecurity #OffensiveSecurity #Offsec #PenetrationTesting #PenTest #Redteam #VulnerabilityManagement #CISO #CORTUS #Logisek

Three questions, in this order. How many systems do you have? How often should each of them be tested? How many tester-days does that add up to? If you cannot answer those three in sequence, next year's security budget is not a plan. It is a negotiation, and you are going into it with anecdotes while the person across the table has a spreadsheet. This is how most testing budgets are actually set: last year's number, plus a bit, minus whatever finance takes back, defended in a meeting with the two or three most alarming findings of the past twelve months. It works often enough to keep being used. It has two failure modes and both are quiet. The first is that demand is never expressed. Your estate grows every year. New services, acquisitions, migrations, a platform team that spun up eleven things last quarter. Testing capacity does not grow on its own. So coverage falls year on year while spend stays flat, and nothing in the budget conversation surfaces that, because coverage is not a number anyone is tracking. The programme degrades invisibly and on schedule. The second is the question you will eventually be asked by someone in finance, and it is entirely fair: Did the money we spent last year actually improve security? We have watched capable security leaders be unable to answer that. Not because it improved or didn't, but because the spend lives in one system and the security outcomes live in another and nothing joins them. You can produce total spend. You can produce open findings. You cannot produce the sentence that connects the two, and without it every budget conversation is a matter of trust rather than evidence. The joined-up version is not complicated in principle. Cost attributed down to the system it was spent on, not just the engagement it was bought as. Coverage per system. Posture per system over time. Then "we spent this here, and this is what happened to it" becomes a sentence you can say out loud. And the forward-looking version of the same data answers the question you actually want to walk into the meeting with: at our current headcount and cadence, what coverage will we achieve next year, and what would it take to reach the coverage we said we wanted? That is a budget request that is difficult to refuse. "We need more" is not. - logisek.com #Cybersecurity #OffensiveSecurity #Offsec #PenetrationTesting #PenTest #Redteam #VulnerabilityManagement #CISO #CORTUS #Logisek

Every #findings tracker has a column called #Owner Go and count how many rows have it filled in. Then count how many of those name a person who still works there, in the role they were in when the report landed. #Unassigned work is the most reliably invisible failure in a #security programme, because it never announces itself. A finding with no owner does not appear in anyone's queue, does not appear in anyone's metrics, does not trigger anyone's escalation, and does not feel like a problem to anyone in particular. It simply persists, quietly, while everything with an owner gets attention. It usually happens for boring reasons. The system spans two teams and each assumed the other had it. The service was inherited from an acquisition. The team that built it was reorganised and the successor team does not consider it theirs. The owner was a named individual rather than a role, and they left in March. The same thing happens one level up, to whole systems, and there it is worse. There is a category of system in every estate that has no owning team, no named contact, no recorded components, and no assessment on file. Nothing about it is broken, exactly. It is simply not attached to the organisation anywhere. It runs, it is reachable, it holds data, and it exists in no one's mental model of what they are responsible for. Those are the systems that turn up in incident reviews with the phrase "we didn't realise that was still in production". We have scoped engagements where the most interesting thing we found was a host nobody could account for. The fix is not a stricter policy about filling in the Owner column. People do not fill in that column because they do not know the answer, and they do not know the answer because ownership lives on the asset, not on the finding. If you know which team owns the system, you know who owns every finding on it, automatically, without anyone typing anything. If you do not know who owns the system, no amount of tracker discipline will invent it. - logisek.com #Cybersecurity #OffensiveSecurity #Offsec #PenetrationTesting #PenTest #Redteam #VulnerabilityManagement #CISO #CORTUS #Logisek