Index
- AI needs an attack path
- Know your own IT
- Assessing risk properly
- Limiting attack paths
- SIEM as a building block
- Avoiding log noise
- AI attacks and zero-days
- Products under scrutiny
- Competence inside the company
AI still needs somewhere to start
AI can search for vulnerabilities, prepare attacks and automate processes. That can happen faster and at a greater scale than before. But it doesn't follow that a firewall suddenly loses its effect, or that properly restricted access rights become meaningless.
An attacker still needs a usable way in: a vulnerability, stolen credentials, a misconfiguration, or a person they can deceive. Even an army of AI bots doesn't override these technical prerequisites. Their speed and scale do, however, need to be factored into how protective measures are designed.
Know your own company and its IT
Which systems do we operate? Which applications run on them? Who is allowed to access what? Which connections are necessary, and which data leaves the company? Anyone who can't answer these questions already has concrete work to do and possibly a competence problem too. That doesn't require a new AI headline.
The CIS Controls v8.1 from the Center for Internet Security, which I translated into German, structure this work into 18 topic areas:
- Inventory and Control of Enterprise Assets
- Inventory and Control of Software Assets
- Data Protection
- Secure Configuration of Enterprise Assets and Software
- Account Management
- Access Control Management
- Continuous Vulnerability Management
- Audit Log Management
- Email and Web Browser Protections
- Malware Defenses
- Data Recovery
- Network Infrastructure Management
- Network Monitoring and Defense
- Security Awareness and Skills Training
- Service Provider Management
- Application Software Security
- Incident Response Management
- Penetration Testing
These measures need to fit your own environment, be implemented step by step and maintained continuously – strictly evidence-based, of course, and with reliable, accountable staff for the various measures and risks. A checklist alone does not protect a company, but competence instead of ignorance does.
Assessing risk requires insight and expertise
A risk assessment looks at, among other things, the possible impact and the likelihood of an incident. Understanding the actual circumstances is especially necessary for the latter.
Imagine driving on holiday in a car with no fuel gauge and no odometer. How high is the "probability" that you’ll break down? That’s hard to estimate. The "severity" of an empty tank, on the other hand, is obvious: your car stops.
Anyone who wants to assess risk seriously has to understand their own company, its processes and its IT. Systematic vulnerability handling and continuous monitoring are equally necessary. Without these foundations, a risk assessment lacks the maturity it needs.
Deliberately limiting attack paths, because AI doesn't think
System hardening applies to operating systems as much as to applications. Unneeded services are switched off, permissions are restricted, and secure configurations are defined in a traceable way. An up-to-date software version alone isn't enough.
Networks are segmented by protection needs. Permitted connections are deliberately defined and monitored, including within the company and for outbound access. Administrative interfaces and API paths get matching access restrictions. Privileged accounts need individual credentials and clearly limited authority. Using the same password for several admin accounts makes an attacker's job considerably easier.
Current IoC feeds provide known indicators of malicious activity, such as IP addresses, domains, URLs and file hashes. Matching them regularly against your own environment’s data enables targeted detection and automated countermeasures.
The hash values of running processes’ executable files belong here too: if a known malware hash is detected, the process must be blocked from starting automatically. If the process is already running, it must be terminated automatically right away. If necessary, the system is additionally isolated.
Vulnerability management, in turn, assesses findings and tracks their handling end to end. That includes patches, targeted configuration changes, additional access restrictions, or retiring unsuitable systems.
This work requires knowledge and experience. The underlying principles have been known for decades.
The central building block in the detection stack: SIEM
In the SIEM (Security Information and Event Management), security-relevant data from connected systems is brought together, compared and evaluated. Which data is needed, and which rules trigger meaningful alerts and automated responses, has to be worked out and tested for your own environment.
In one of my projects monitoring a database cluster, this included provisioning and evaluating several of the database's data streams as well as analysing SQL queries. The processes had to be understood, and suitable decoders and rules developed and tested.
An SQL query that runs forever, whose behaviour nobody understands, or that was simply built inefficiently, can tie up resources and disrupt business processes. That, too, is part of IT security. AI hacking bots and hoodie-wearing hackers are only part of the picture. Even simple disruptions or routine customer requests can have a significant impact on poorly built applications. AI and hackers often just make a company's own shortcomings visible.
SIEM and IT infrastructure monitoring need to show what normal operation of your own environment looks like. This operational baseline is the basis for spotting deviations, assessing developments and deriving forecasts.
Individual playbooks can respond automatically to clearly defined events. Which connection may be blocked, or which system may be isolated, has to be clarified and tested beforehand.
Log noise costs money too
Automated attacks and constantly repeated requests sometimes generate substantial volumes of logs. Transferring, processing and storing them can drive up costs for cloud services, storage and volume-based licences. At the same time, log noise makes it harder to see other relevant events.
That's why this also needs a prompt response: identify causes, limit unwanted access as early as possible, and specifically address recurring patterns. Security-relevant traces must be preserved in the process. After all, there's a good reason systems generate log messages in the first place!
AI attacks and zero-day gaps
If an attack on a system succeeds, its further spread has to be stopped. Operations need to continue via fallback options (keywords: High Availability/HA and Load Balancing/LB), or be restored within an accepted period of disruption. How long a disruption is acceptable is something the company decides before the real event, not during it.
That requires Business Continuity Management (BCM), suitable processes for IT security incidents, and tested, effective playbooks. That includes clear responsibilities, reachable contacts, protected backups and regularly rehearsed procedures.
Digital forensics and evidence preservation also need to be prepared in advance. The origin, integrity and handling of evidence must be documented in a traceable way. The legal requirements for collecting, storing and using it belong here too. That can be decisive in a legal dispute or in a claim against an insurer. Technically interesting data alone doesn't fulfil that purpose. An emergency plan that has never been tested leaves key questions unanswered.
Security products belong on the test bench
What capabilities does a product actually offer? In a sales presentation, a product can always do everything, and then some. A proper cost-benefit calculation includes not just licence fees but also real-world capabilities, integration, operation, maintenance and the staffing effort required. What matters is the demonstrable contribution the product makes to security.
IT security can decide a company's economic success and its technical survival. Selling IT security solutions should accordingly be in the hands of experts with demonstrable practical experience. Anyone offering such solutions has to be able to assess their capabilities, limits and operational impact themselves. Put simply: if your car's engine is damaged, it's the mechanic who gives you the right diagnosis, not a salesperson!
Anyone dazzled by the AI hype also falls for snake oil. That can happen with major vendors just as much as with opportunists who use AI slop to fake competence.
Competence has to reach the whole company
Management and IT have to carry this work together. That takes time, resources and qualified staff. Where knowledge is missing, training and targeted external support are part of the answer. A reputable service provider passes on their knowledge.
Policies are developed together with the teams involved. They have to describe the actual workflows, be known, and actually be applied. Their effectiveness is reviewed regularly; identified gaps are fixed.
That's work. Ongoing work. Another product licence won't do it for anyone. My own consultancy, Gray-Hat IT-Security Consulting, follows the same principle: sharing knowledge rather than just selling it.
Save on the licence, not on the expertise!