Brute Force Attacks are on the rise – do I need a SIRP? 

Brute Force Attacks are on the rise – do I need a SIRP? 

Technology means endless opportunities, but also endless headaches. Scripting, machine learning, AIs and easier access to more advanced systems does not mean your every-day becomes easier – it also means that the every-day of the malicious hacker becomes easier. 

It is said that internet users have to keep track of about 190 passwords and PINs. Obviously there will be a lot of QWERTY and related phrases. And this renders opportunity to hackers.

Brute force attacks, simply trying again, again and again until you find that weak spot and gain access for your ransomware, it’s a bit like the river wearing on a lever – sooner or later, it will break. Unless you have a regular schedule to test, train and openly look at your weaknesses and issues in order to do something about them.

Would you rather evacuate the whole valley, or work a bit on the lever every now and then?

Since the last years of increasing awareness of high-end sophisticated hacking, many has focused on BFA hacking and increased security in those areas. Hence hackers rely a lot on BFA. They are quite right to do so; BFA and phishing is actually keeping it simple and in fact easy way to gain access to secured information where it shouldn’t be possible.

McAfee estimates a 118% increase in ransomware attacks delivered by BFA and RDP ports. Obviously, figures like these can be questionable because they rely on what is actually reported and by whom. Still, as statistics do, they show, if not fact but tendencies. And these tendencies we can not just ignore.

Ask yourself – if your worst competitor had no ethics, what could they do? Would they gain access to your network? To your data? Your systems? Would they simply lock you out and demand money for the key? Or something more malicious? What would your revenue loss be if something like this happened? And what would the loss of confidence in you or your company be? Should it leak out how close you were to a “hostile takeover”?

Do I really need a SIRP? 

The short answer is yes, you really do. 

When an incident has occurred or a breach is discovered you need a plan, which will tell you how to handle the situation, and will help you avoid mistakes you are likely to make when in crisis mode. A Security Incident Response Policy (SIRP), ensures that your organization has both the controls to detect security incidents, and the processes to resolve them. 

Recommended features of your SIRP

To be effective, the response plan should include the features listed below. Try not to overcomplicate the process. Instead, strive to keep the policy as simple and easy as possible. No one likes to read it any more than you like to write it. 

A clear definition of a ‘breach’ 

What kind of action will constitute a breach, and consequently activate the plan? Not all events will affect your company in the same way, or at all. A DDoS (distributed denial-of-service)-attack or a BFA, is of much more concern, than an attempted phishing email. 

When someone tries to scan a firewall for open ports or when your antivirus reports that a system might be compromised, that is a security alert

An alert can be a false positive, meaning it is not necessarily a real threat, or something that needs investigation. It is important to find the right balance, because if the alert triggers are too sensitive, it’ll be like the boy who cried wolf, no one will listen in the end. But if the triggers are too slack you might miss warnings of actual, serious incidents. 

An investigated alert becomes an incident

When you decide to investigate an alert, it becomes an incident. Hence, you should work continuously to make the balance between security alert and security incident as efficient as possible. 

Typically a breach includes any (attempted) theft or intrusion of electronic data files containing sensitive information about customers, clients, or employees or sensitive company information like trade secrets. 

An incident response team

Having an incident response team – internal or external – is necessary in case of an emergency. The plan should therefore include a list of names, contact information and area of responsibility as well as mandate. 

The size of the team depends on the company size, the industry and the complexity of the company’s business. 

Necessary tools 

It is important that the team has the information and the tools necessary for handling the incident. For example, all necessary information gathered, including network diagrams, policies- and incident response plans, IP addresses and so forth. You might also want to prepare for common attacks, such as DDoS-attacks (distributed denial-of-service attacks), with technical infrastructure in place.

A process for handling the incident 

The objective of the plan is to ensure that the response team can analyze the breach (why and how it occurred), limit the potential damage and take proactive actions for it not to happen again in the future. 

Step-by-step guidelines 

The plan should provide step-by-step guidelines on what actions that should be taken, when an incident, i.e. a breach, occurs. Every member of the response team should be assigned responsibilities and mandates that reflect their expertise.

Cautiously document your actions

It is also important to cautiously document the breach and the measurements taken by the team. This documentation will show whether or not the response team followed the process stated in the SIRP potentially revealing weaknesses, either in the SIRP or in the team’s training. Furthermore, if the breach involved sensitive data protected by law, e.g. personally identifiable information, the documentation may be required by the authorities. 

You might be subject to notification requirements

In some cases you are required by law to report the breach to a state or federal agency or/and to the individuals whose data has been compromised. Sometimes combined with a time restraint. This is often the case regarding sensitive data, like health records or financial transactions. 

If the company is subject to such notification requirements this too should be stated in the SIRP. 


When the breach has been handled and contained, you should evaluate the measures taken by the response team. What did they do, what were the consequences and what lessons did they learn from the process? The subject is not to find scapegoats or point fingers, but to adjust the plan or offer additional training, if necessary.

Sooner or later security challenges happen, it is merely a question of time. But if you are prepared and have the counter-measures in place, the consequences to you, your company and your customers will be far less severe. So planning ahead it’s the foremost thing to do for any responsible leader. Why not start today?