It's Not Just About Controls: 3 Brand New Cyber Strategies You Can Deploy Quickly

 

For as long as I have been a technical writer in the world of Cybersecurity, I have never been asked this one question:  “What is a control?”  I was asked this when I was walking down the Prairie Path, a beautiful preserve located here in Chicago.  Someone stopped me to say “hi”, and the conversation started as to what we do.

When I told him I was in Cyber, that that was the first question that came out of his mouth. So, I answered:  “Well, a control is defensive mechanism that is put into place to protect your digital assets”.  He scratched his head even more and just walked away.  I did not forget about this, on the way back, even I started thinking:  “What exactly is a control”?  “What does it even  look like?”

So that gave me the inspiration for today’s blog.  Keep in mind that this is just an overview, more specifics about controls will come in future blogs.  Generally speaking, there three different  ones:

1)     The Preventative:

In this kind of scenario, you have a CISO and an IT Security team that is initiative-taking in their job responsibilities.  Meaning, they want to get the controls out and deploy them before the Cyberattacker can break through the lines of defense.

2)     The Detective:

This is where you implement a control where you will alert you only after a Cyberattacker has broken through.  Obviously, this is not a situation that you ideally want to be in, but at least it will allow your IT Security Team to get an early jump on containing any damage that could have already been started.

3)     The Corrective:

This is the situation in which you have been hit by a security breach and are scrambling quickly to deploy any kind of control that you can to avoid further fires.  Obviously, this is a situation that you never, ever want to be in!!!

So now the next  question comes up:  “When do you deploy controls when you don’t even know what tomorrow looks like?”  The truth of the matter is that the deployment of controls is not an exact science.  Rather, it is an art.  IMHO, controls should be deployed immediately once a Risk Assessment has been conducted has been done, and you know what your most vulnerable digital assets are.

But there are other steps that you, and your IT Security team can also take in conjunction with the deployment of controls to further help beef your lines of defenses.  According to can article I read this morning (which also further inspired me to write about controls), this can be compared to “avoiding potholes on the road”.  So, here are some ideas:

1)     Minimization:

I have always talked about one of the best ways to keep your attack surface to as little as possible is to use only those devices that you absolutely need but place them strategically.  This especially holds true for network security devices.  Instead of getting ten of them, why not try and use just three?  Another area where “bloat” can be eliminated is in the software builds that you engage in.  For example, rather than using extra components that add more bells and whistles, why don’t you just create something that is much leaner, but also, delivers what the customer is looking for?  By having “bloated” applications, you are simply putting in more points of entry for the Cyberattacker, thus putting your customer at an even graver risk.  This is where the importance of a Software Bill of Materials (also known as an “SBOM”) comes into critical play.

2)     Use What Is Given:

It happens to be the case that your entire IT and Network Infrastructure is in Cloud; you are given a wide array of security tools that you can work with.  This is especially true of Microsoft Azure. They give a lot, so make use of it, because there should not be an extra charge for them (it is part of your monthly subscription).  But keep in mind that you are responsible for the proper configuration of them!!!  If you are not sure how to do this, is it always best to work with a Cloud Service Provider (also known as a “CSP”).

3)     Generative AI:

With this explosion, a new trend has started, and that is to make use of what are known as “Non-Human Identities”, or “NHIs”.  These are, they are like small robots that have been created by Generative AI to help automate certain processes.  While the common thinking is that they can access anything at any time, the truth is that they also need to be given login credentials as well.  So in this regard, it is also that you maintain a strong security policy here as well and even go to the point of using Password Managers that has. been created exclusively for these “agents”.  They should also be given access only when it is absolutely needed (in the world of Privileged Access Management, this is technically known as “Just in Time”).  It should be noted here also that up to 95% of businesses use these small robots today, thus the need to further them even more is now of paramount importance as well.  (SOURCE :  https://cloudsecurityalliance.org/artifacts/state-of-non-human-identity-security-survey-report)

My Thoughts On This :

While  the discussion of controls will be covered in future blogs, the CISO and the IT Security team should not just be obsessed with just them.  Remember, they are just one part of creating that great Cybersecurity machine that will always be a work in process.

The 4 Hidden Risks Of Multi Region Cloud Architectures: How They Can Be Avoided

 

Whenever you sign for a hosting account or even open a subscription with AWS or Microsoft Azure, the excitement comes in when you see all the tools that you have at your disposal.  It can be confusing and daunting, but it is exciting for sure.  One of the areas that sort of “turns me on” (for lack of a better term) is when you get to choose the Datacenter in which you want stuff located at.

It can be anything, from where you want your website hosted at to where you want your dedicated server to stationed at.  While the allure of the Cloud is awesome, and its advantages are great, such as fixed pricing and the ability to scale up or down in just a matter of seconds, one thing you really need to ask, and you probably won’t get the answer to is:  “Where is my data exactly located at?”

Just because you chose to have a datacenter in the US, it does not technically mean that everything in your account will be located there.  For example, if your Internet Service Provider (ISP) has multiple Datacenters around the world, there is an extremely high chance that your digital assets could be scattered about as well.

A notable example of this is Microsoft Azure.  It has Datacenters in many countries, and if you set up a bunch of Virtual Machines, it could be scattered about as well.  This is known as “Multi Cloud Architectures”, and it can be technically defined as follows:

“Multicloud is the practice of using the services of multiple cloud providers to optimize workload performance, increase flexibility, and mitigate the risks of relying on any one vendor.”

(SOURCE:  https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-multi-cloud)

There are risks by taking  this approach, for example:

1)     Configuration Drift:

This happens when you create a virtualized IT and Network Infrastructure, for example in Microsoft Azure.  While the rules that you may have set up for your firewalls, network intrusion devices, routers, etc.  may appear to have been configured in a US based Datacenter, but the chances are that it could have “spilled” over to other Datacenters, so everything may not be completely equal in the end, with regards to this.  Even the policies that you have established could also vary a little.  The risk here?  Given these inconsistencies, this simply creates a backdoor for the Cyberattacker to penetrate into.  From here, there could very easily launch a Supply Chain attack, very much like we saw with the Solar Winds one a few years ago.

2)     IAM:

This is an acronym that stands for “Identity and Access Management”.  Essentially this is the area of Cybersecurity where you establish the polices and rules for assigning the rights, privileges, and permissions to your employees to access shared resources.  But if you set something up here in the US, there is no guarantee that it will follow the same kind of consistency in other globally based Datacenters.  The huge risk here is that of password compromise, especially when it comes to super user passwords, such as those assigned to Network Administrators, Database Administrators, members of the IT Security team, etc.

3)     Data:

Yes, Cloud is the best place to back up your data, and even for my tech writing business, I do this also.  I do not store anything On Premises.  Obviously, you will want to keep backups, and as far as possible, you will want to keep this in a US Datacenter.  But once again, there is no guarantee that this will happen either.  This means that if your data is stored in different datacenters around the world, they will be subject to that nation’s data privacy laws.  If the laws are lax and not proactively enforced, again, this is a huge place where the Cyberattacker can easily penetrate very covertly.  There is a lot they can do with your datasets, such as selling them on the Dark Web, launching Extortion Attacks, or even assuming the full and complete identities of the victims.

4)     The Laws:

Back to the above, if your datasets are stored in global Datacenters, you will also be subject to their Data Privacy laws.  For example, if anything is stored in a European based Datacenter, your ISP will be subject to the tenets and provisions of the GDPR.  Although any ramifications will not impact you directly, it is still important to be aware of this, and to ask your ISP questions how compliant they are with these laws.

My Thoughts On This:

In the end really, you do not have much control if any of your digital assets are being hosted and controlled in different Datacenters around the world.  All you can pretty much do is just be proactive on your end, and use all of the security tools that are available to your disposal (for example, Microsoft Azure has a ton of them you can use at no extra cost to you), and to keep an eye on any alerts that you may get from your ISP.

But for the ISP here are some of the steps that they can take to mitigate any kind of risk:

Ø  Maintaining a strong consistency with their digital footprint.

Ø  Encryption must always be used, no matter what!!!

Ø  Monitoring and logging on a real time basis is necessary, and they must make this available to you as well to keep an eye out for any abnormal or suspicious behavior.

Ø  Network security must be implemented on a global basis, with the same kind of consistency throughout.

Ø  They must also have failovers.  For example, if a datacenter fails in one location, it must “roll over” to a new one somewhere in the world, with hardly noticeable downtime to you.

How Not To Use Synthetic Data In Generative AI

 

As I have described in my previous blogs about Generative AI models, the fuel that keeps their engine running is data – and lots of it.  But, just like gas for your car, the datasets that are fed into the model must be filtered, cleansed, and optimized.  If not, the model will have skewed data in them, which will generate the wrong kind of output that you really cannot make any use of. 

But datasets that you need for your model may not be readily available right when you need it the most.   So, the best resolution to this dilemma is create what is known as “Synthetic Data”.  It can be technically defined as follows:

“Synthetic data is information that's been generated on a computer to augment or replace real data to improve AI models, protect sensitive data, and mitigate bias.”

(SOURCE :  https://research.ibm.com/blog/what-is-synthetic-data)

So, as you can see, you are using an algorithm (which could also be powered by Generative AI) to create “fake” data that has not yet been found in the real world, but it could make it is their eventually.  Using Synthetic Data is a fantastic way to create datasets that you need to at least start training your models on. 

The one caveat here is that it is always best to use real world data first.

But the scary part of this is that it is expected that by the year of 2030, most of the datasets used in Generative AI models will be all synthetic.  It is also important to keep in mind that that the actual concept of creating and using Synthetic Data is not anything new, in fact it dates to many years ago.  It is not until now that its popularity has really picked up.

But as we all know, anything that is data related is a prime target for the Cyberattacker.  This event includes Synthetic Data.  You might be asking this question:  “If it is fake data, why would they then be interested in it?” 

Well, the truth of the matter is that even if the Cyberattacker were able to heist some fake data, they can still use that to try to extrapolate what the real data could look like.  Then, if it seems too valuable enough, they will then pursue it.

So, while Synthetic Data theoretically may have no value to it, it is still particularly important to try to keep them as secure as possible.  Here are some keys in which you can do this:

1)     The Outliers:

As it was just described, even from within your Synthetic Data, you will want to make sure that there are no outliers that exist.  Apart from screwing up the outputs, the Cyberattacker will take quick notice of this, and pounce upon them.  That is why even your real-world data needs to be thoroughly checked for this.

2)     The Risks:

To make sure that you have not contaminated any of the algorithms by using Synthetic Data, you will want to run each and every time at least a Vulnerability Scan (preferable a Penetration Test) to make sure that there are no vulnerabilities that have come about as a result.  If they have, you need to remediate it quickly, as this will be an easy backdoor for  the Cyberattacker to penetrate through and totally wreak havoc on your models.

3)     Longevity:

You do not want to keep Synthetic Data any longer than you absolutely need to.  This even holds true for real world data.  By keeping both kinds of datasets for an extended period, because if you do, you are only exposing yourself to becoming the victim of a security breach.  Remember, Synthetic Data can be created very quickly, if you ever need to have them again.  So, there should be  no questions asked about discarding them.

My Thoughts on This:

Here are some other things to keep in mind when creating and making use of Synthetic Data:

Ø  Never, every 100% on Synthetic Data to train your Generative AI models.  By doing so, they will become “out of touch” with reality, and when the time comes that you feed into its real-world data, you could quite easily cause your model and its algorithms to completely crash.

 

Ø  It is always best to use real world data.  But be careful about the sources where you get them from.  Always vet out your suppliers, because if they provide you with something that has been trademarked or copyrighted (such as content from a manuscript), you could very well be facing a serious lawsuit.

 

Ø  The Data Privacy laws, such as those of the CCPA and the GDPR, also have tenets and provisions about using Synthetic Data.  They treat any misuse of that in the same way as real-world data.  Therefore, you will always want to make sure that your controls that you have over them are optimized all the time.

 

Ø  Do not even think about coming Synthetic Data and real-world data together. Not only will this mess up the models, but if you combine some real data about your customers mixed in with fake ones, you will be brewing a lot of trouble for yourself.  In other words, decide which one to use, and stick with only that.

 

Finally, keep in mind that it is particularly important that you keep an overall eye on your models and algorithms.  You will always want to make sure that they are optimized not only to give you the best results possible, but to also mitigate the risks of a security breach happening to them.

 

Breaking Down What Secure By Design Means For Generative AI

 

Just this past Thursday, I gave a presentation to about 150 people (coworkers of mine) about Generative AI and Cybersecurity.  I touched upon a few use cases, and the kinds of questions that a client or a prospect might ask if they are interested in this kind of solution. 

At the end of the presentation, a question was asked to me:  “How do I safeguard my PII (Personal Identifiable Information) data if I know I am submitting to an application that uses Generative AI?”

I had to think about this one, because obviously I did not know the answer.  There is no silver bullet answer to this one, so this can be difficult to answer.  As far as I know at the present time, there are no concrete controls in place for this. 

But rather, the security must be baked in as soon as you start the process of building your Generative AI model and eventually deploying into your production environment. 

This concept is technically known as “Secure by Design”, and it can be defined as follows:

“Secure by design is a philosophy and approach that prioritizes security considerations at every stage of the development lifecycle, ensuring that systems and products are inherently secure from the start. Instead of adding security as an afterthought, secure by design integrates security measures throughout the entire design process, making it a foundational element of the product or system.”

(SOURCE:  Google Search)

In other words, security is not after though after deployment of anything, but rather, it is planned out from the very beginning to make sure that nothing has been left behind.  This has started to become the mantra in the world of software development, but now, given the evolution of Generative AI and its long-term potential, it is now being deployed here as well.

This is a concept that has been strongly advocated by CISA, and to read a comprehensive white paper, click on the link below:

http://cyberresources.solutions/Blogs/CSIA_SBD.pdf

This is an initiative-taking approach to help secure your Generative AI models, right from the very beginning.  Because of the confusion of what means “secure” in this realm of the world, at the present time, there is a reactive approach that is being taken to this.  Here are some of the consequences:

1)     Data Poisoning:

One of the cardinal rules in Generative AI is that you want all the datasets that you will be using to be as “cleansed” as possible, meaning that they are free from any or other erroneous bits of information.  But in this regard, the Cyberattacker, and unknowing to you, can easily insert some kind of malicious payload into them.  This will eventually lead to data exfiltration or data leakages happening.

2)     Prompt Engineering:

This is the art of Generative AI in which it teaches you how to create specific queries to get the best answers (or outputs) that are possible.  It takes time to learn all of this.  But, the Cyberattacker is stealthy enough that they can inject malicious prompts into your Generative AI model, thus having it give out answers that it should not be given. 

3)     Deserialization:

This is the process where the Generative AI model can take bits of data and transform them into other types, especially when they are needed for software development.  Once again, a malicious payload can be deployed here by the Cyberattacker to create a back door to get into the software application after it has been deployed.

So how can Secure by Design come to work here?  It does it primarily by adopting the principles of what is know as “Machine Learning Security Operations”, or “ML” SecOps for short.  This is where the Generative AI, the Operations team, and the IT Security team come together in one unison to make sure that the Generative AI model has security baked into right from the very beginning of the development lifecycle.

Some of its components are as follows:

Ø  Threat Modeling:  This is where future threat variants are predicted, to help beef up the lines of defenses.

 

Ø  Data Preparation:  This is where all efforts are made to ensure that all the collected data sets are cleansed and optimized, as stated earlier.

 

Ø  Testing:  You want to evaluate the Generative AI model as it is being developed throughout its various stages.  A tool that can be used here are what are known as “model scanners”.

 

Ø  Continuous Monitoring:  Even after the Generative AI model has been deployed into the production environment, you will still want to keep an eye on it and monitor any rogue network traffic that may come its way.

 

Ø  Penetration Testing:  This is where you will want the Red and Blue Teams to launch comprehensive exercises so that any gaps or vulnerabilities can be found and quickly remediated.  You do not want to wait until the end of this.

 

Ø  Firewalls:  One of the best tools that you can use to protect your Generative AI model is using something like a Next Generation Firewall.  These are much more sophisticated versions of the traditional Firewall and can analyze data packets at a much more granular level.

 

Ø  Incident Response:  In this regard, you will want to have playbooks that can be automatically triggered to help contain a security breach to your Generative AI model should it ever occur.

My Thoughts on This:

Even despite using the concepts of MLSecOps, you must have bought it from every key stakeholder that participates in the development of every aspect of the Generative AI development process.  This event also includes C-Suite. 

They must know what is going on, and they cannot plea ignorance or that they have not been informed.  There must be a Change Management Committee that will oversee any changes to the Generative Model after it has been developed and deployed into the production environment.

So, in the end I guess, the best answer for tight as to how to safeguard your PII is just as initiative-taking on your end as the MLSecOps team would be as well.  Trust your gut.  If something does not feel right, do not enter your private and confidential information into it.

How Being Cyber Rigid Can Cost You Dearly

 

In the world of Cybersecurity today, having a plan of action to not only put our security breaches but to have the ability to restore back to mission critical operations is an absolute must.  After all, in the end, you don’t  want to lose customers, or even more importantly, your brand reputation.  You need to have your documents in place, such as the Incident Response, Disaster Recovery, and Business Continuity. 

You will always hear that it is also of paramount importance to keep rehearsing and practicing.  But in the end, this could lead to something that you do not want to happen:  Rigidity, in a time when you need to have fluidity, to keep up with the ever-changing Cyber Threat Landscape.

How does one break away from this mold?  Here are some tips to help with this:

1)     Do not become overly obsessed:

The CISO very often thinks that just because they have a set of procedures and documents that they can follow, all will be good if they are hit with a security breach.  But keep in mind that each threat variant is different from the next, and even in the past.  The plans that you have created and worked so hard for may not hold true as a result.  While it is important that you have them, and keep practicing them, you and your IT Security team should not be so locked into the procedures.  Yes, have them, but use that as a baseline only to keep an open mind as to what you could be facing out there as well.  In other words:  Having an impressive set of procedures and protocols does not always equal protection.  This can also be easily compared by having too many security tools.  This may lead you to think more is better, but this is not the case as this only increases your attack surface that much more.

2)     The C-Suite:

Yes, everybody loves to blame the IT department for anything and everything that can go wrong.  But yet once again, this is another huge error in thinking.  The IT Security team cannot be held accountable for each and everything  that happens.  In other words, there must be accountability at other levels as well.  What I am talking about here is C-Suite.  If a security breach does happen, they need to remain cool and collected to figure out how to combat it.  Once there is clear leadership and logic prevails, everybody else all the way to the bottom of the employee rung will follow suit.  Remember in the end, if you are hit by a security breach, panic will not help at all, but rather, a steady and guiding hand from the top is what will be needed the most.

3)     Simplicity:

Today, many businesses rely upon what are known as Playbooks.  These are now powered by Generative AI and are automatically triggered to contain a security breach if one does indeed happen.  But, there is no need to have millions of them.  Rather, create and keep the ones that you think you will need the most, and just use that as a baseline.  In other words, there is no need to fill in all the blanks.  Leave a few open so that you can be flexible and open minded when responding to a particular threat variant.  Also remember count on your training and instinct to respond.

4)     Psychology:

There is yet another error in thinking that a threat variant will only impact the digital assets that have been targeted.  While this is true to a certain extent, remember there are also other victims as well, such as your employees, other key stakeholders, and even more importantly your customers.  Your IT Security team needs to have this in the back of their minds as they put out a security breach.  Yes, this creates more pressure, but if you have great leadership from the top, people will think with a logical mind.  To put it another way, this is where keeping the mindset of being  proactive is an absolute must and will pay huge dividends in the end.

5)     Reality:

One of the best ways to keep your IT Security team in having that initiative-taking mindset is to train them on a regular basis with real world security scenarios.  I’m not just talking about security awareness training.  I mean putting them through the real grind of what is out there.  You can even make use of Generative AI to create these types and kinds of scenarios as well.

My Thoughts on This:

This all comes down to what is known as “Cyber Resiliency”.  Many people have different  ways of defining it, a rubber band.  Your IT Security team must be  able to flex and bend that much and  have the ability to come back  to a state of normalcy whatever the situation may be.  One other great area in which you can maintain that initiative-taking mindset is to model potential threat variants not based on past breach profiles, but rather from what is known as “Synthetic Data”.

This is where you use a Generative AI model(s) to create what is known as “Fake Data” to easily accomplish this task.  Also, get rid of the siloed approach.  Working as a team together is also what matters most in the Cyber world of today.

The 5 Hidden Risks Of Cyber Mergers & Acquistions - How To Overcome Them

 

Given both the economic and political uncertainty here in the United States largely because of the tariffs, Merger and Acquisition activity has slowed down.  It is by no means as robust as it once was since last year, but here and there it is happening. 

Even in the Cybersecurity world, it is still happening.  While it may sound like all glitz and glamor that one company is buying out another, there is a lot that goes behind the scenes, there is also a lot of risk as well. 

Since there is not a lot written about it, I am going to talk about it here, in this blog.  There are a few of them, so here they are:

1)     The Due Diligence:

Most C-Suite is obsessed with such things as the bottom line, valuation, what the acquisition of new products and services brings to the table, getting a big customer base, etc.  But there are other things to think about here as well.  But when it comes to the digital assets, Due Diligence is a sheer must.  The best way to get started on this is to conduct a Risk Assessment of the company that you are about to acquire, just like you have done for your own digital assets (hopefully).  Apart from finding any vulnerabilities or gaps, you need to assess the following as well:

Ø  Existing security policies, and any that are in the pipeline.

Ø  The history of their compliance.  For example, are they “clean” with regards to the data privacy laws?  If not, what steps are they taking to correct that?

Ø  What is the password policy like?  Are they making use of a Password Manager?

Ø  What are the Identity Access Management (IAM) and Privileged Access Management (PAM) like?  Are they being strictly enforced?

If you do not do a comprehensive check of all of this, you will be held responsible for any security that may occur down the road.

2)     Access Control:

Although this was just described, you must fully ensure that whatever IAM and PAM policies of the company that you are about to buy are fully compatible with what you have.  If not, login credentials can easily get heisted, and if the merger is made public, the Cyberattacker will be on the hunt for this.  Some things that you need to pay attention to include the following very carefully:

Ø  The kinds of usernames and passwords that your new employees have used now, and in the past.

Ø  How often the passwords have been reset.

Ø  After you buy out the company, if they still have access to those same login credentials.

The best thing you can do in this regard is to completely eradicate everything that they have had in the past, but it is still important to see their previous login history and especially take note if they have a rash of unsuccessful login attempts.

3)     IT/Network Infrastructures:

When you buy out that company, you are not just getting the digital assets, but you are also getting their entire IT and Network Infrastructure as well.  Before you just try to merge everything together, you need to determine how much of it is On Prem and how much of it exists in the Cloud.  Once you have determined all of that, you then need to a phased in approach (technically, a sandboxed one) to make sure that it will behave “nicely” with what you already have.  The bottom line is that you need to make sure that once you finally merge everything over, you need to do another full-blown Penetration Test to make sure that there are no new gaps and vulnerabilities that have just popped up.  If they have, then you need to immediately remediate them.

4)     Social Engineering:

Just after the M and an activity has transpired, this is yet another prime time for the Cyberattacker to make their move.  This is where Social Engineering comes into play.  They know that everybody will be at one of their weakest moments at this point in time,  thus they can easily pray on vulnerable emotions.  Before and after,  and even in the long term, you must train both your own and the new employees in the tactics that the Cyberattacker can use in this regard.  You must enhance and increase  the frequency of your security awareness training programs, especially when to comes to Phishing and  Deepfakes.

5)     The Insider Threat:

Just before or after you have merged the two entities together, unfortunately, there could be some layoffs from employees.  This could create some negative feelings obviously, so therefore you will want to address this with the employees who have been let go.  Some ways that you can cushion the blow include are offering a severance package, and even career counseling.  If possible,  try to locate them into a different role after the merger, if at all possible.  Also, there is the threat of intentional data leakages  or data exfiltration, so you will need to make sure that the controls are in place for that as well, and that your IT Security team is on a continual watch for any signs of abnormal or malicious behavior.

My Thoughts on This:

Well, there are some key tips on how you can cut down the risks when you buy out another company.  However, it is also important to keep in mind that Mergers and Acquisitions are not just about the bottom line.  There is also the human factor, and if you treat your new employees with the respect and acknowledgement that they deserve, this will carry you a long way in terms of being Cybersecurity safe.

Detail Is Important, But Holism Is Even More To Incident Response

 

Some time ago, I wrote a blog about metrics and KPIs, and how nobody really likes to be judged by them, no matter what the industry is.  Well, the same is said to be about Cybersecurity as well.  Probably one of the two most important ones are the:

Ø  The Mean Time to Detect (MTTD):  This reflects how long it takes an IT Security team  to detect a threat variant.

 

Ø  The Mean Time to Respond (MMTR):  This reflects how long it takes for the IT Security team to make a security breach, if one is occurring.

But one thing I failed to mention in that blog post is that metrics are also key in these following documents:

Ø  Incident Response:  This is the plan that details how an IT Security team should respond to an incident.

 

Ø  Disaster Recovery:  This is the plan that provides not just how the IT Security team, but the entire company, should proceed to restore mission critical processes and functions.

 

Ø  Business Continuity:  This is the plan that provides guidance as to how the company should restore back to a state of normalcy, at least the same or better than what they were before.

 

For the purposes of this blog, we will just focus on Incident Response.  In today’s times, and especially with the advent of Generative AI, simply creating a document and booking it back on the shelf will no longer suffice.  Rather, a much more comprehensive approach needs to be taken, and this is technically referred to as the “Cyber Incident Response Program”, also known as the “CSIRP” for short.  It is a policy that maps out the following:

Ø  Responsibilities of all the team members.

 

Ø  The expected outcomes.

 

Ø  All the objectives that Incident Response have been met, and better yet even exceed expectations.

One of the key benefits of taking this holistic type of approach is that all employees will be able to understand the ramifications and gravity of just how seriously Incident Response should be taken.  This is particularly for C-Suite,  whose main vision of the company is unfortunately driven by just pure numbers. 

By having this kind of grasp of it, it is hoped that that they will also see just how important Cybersecurity should be taken, and that they should get away from the thinking that “if it hasn’t happened to us, then it probably never will”.  In this regard, it is also important for the CISO to create this kind of policy keeping the various Cyber priorities in mind.  Meaning, one size fits all document will no longer work.  Rather, documentation needs to be created for each kind of threat that can exist.  For example, there should be one dealing Ransomware, one for countering a Phishing attack, etc.  True, this is a tall order, but here are two ways in which this can be broken down:

1)     Take the whole view:

Just do not restrict you and your IT Security team to just the well-known and established metrics and KPIs.  Rather, try to back this trend by first taking a critical look at all the data that you have collected about any security breaches that may have hit your business.  From there, see any unhidden trends that you can create a new metric out of, and try to apply that for the future.  Some key areas that should be examined include:

Ø  Efficiencies

 

Ø  Any gaps, weaknesses, or vulnerabilities that went undetected which resulted in that particular security breach occurring.

 

Ø  The resources you need.  Trying to put this in either quantitative or qualitative terms will go a long way when approaching the other members of the C-Suite when it comes time to ask for funding your Cyber-based initiatives.

 

2)     Usefulness:

After you have defined your new metrics and  KPIs for the CSIRP, it is important at some later point in time for both you and your IT Security team to take stock of them and evaluate each one of them, and determine how they can be made going better into the future.  A good one to look at here is vulnerability detection.  Are you not only fast enough to find them, but also to remediate them?  If the number is lower than you want it to be, then you know that metric needs to be refined to be where you want to be. But keep in mind that refining simply does not mean changing the metric around.  Rather, all the variables that go into it need to be very carefully looked at, which is a direct function of what your IT Security team needs to be doing.

3)     Proactiveness:

It is important to keep in mind that you should not let your newly created metrics and KPIs for the CSRIP go stale.  Rather, you also need to be initiative-taking about them and determine which ones should be retired and if any other new ones must be created.  Remember, the Cyber Threat Landscape is always changing,  and the metrics and KPIs that you initially produced need to reflect that.  In other words, it is a process of evolvement, and it should not ever be viewed as merely as a static one.

4)     Communications:

You and your IT Security team need to get away from living in the world of silos.  Whatever you do in the CSIRP will impact everybody else in your company, and this CSIRP and the benefits that it brings to the table need to be clearly and effectively communicated, in a transparent way.

My Thoughts on This:

One of the other primary benefits of creating and implementing a CSIRP is that this will help you immensely to come into compliance with the many data privacy laws that abound today, such as the GDPR and the CCPA.  But even more importantly, this will help to mitigate the chances of any audits being made by regulators and facing severe financial penalties.