CrowdStrike One Year Later: 3 Key Lessons Learned

 

Well guess what people?  It has been a year since the CrowdStrike fiasco, and from what we know, it was the biggest Cybersecurity  fiasco to happen in a long time.  It cost at least $5.4 Billion in overall damage.  It became known as a “Supply Chain Attack”, in that only one point of entry is used by the Cyberattacker to deliver the malicious payload, so that it can inflict damage upon thousands of victims in almost a few minutes.  Usually, there can be simultaneous impacts, or they can be delivered in a staggered fashion.

This is what happened with the Solar Winds fiasco.  Through their “Orion” platform, the Cyberattacking group was able to insert a malicious payload through just one point of vulnerability, and from there, once again, thousands of victims were impacted.  So what lessons have been learned from this?  Here is the proverbial laundry list:

1)     Determining what happened:

Following the aftermath, CrowdStrike launched what is called a “Root Cause Analysis”, or “RCA” for short. This is simply Cybersecurity jargon for getting down to the bottom of what exactly happened.  Here is what they found:

Ø  There were a bunch of software validation errors which were the culprit of the disaster. 

Ø  There was not enough testing that was done of these software patches/upgrades, which led to the validation errors.

Ø  A flawed deployment model, which too had not been evaluated, which impacted millions of people around the world, especially the airlines and the airports.

 

2)     More best practices:

As a result of this, many government and private sector entities created their own set of Frameworks to mitigate any chances of a future CrowdStrike incident happening ever again.  Some of the best examples of these are the:

Ø  The ISO 27001:  More information can be found at this link:  https://en.wikipedia.org/wiki/ISO/IEC_27001

It spells out the details for properly managing IT and Network Infrastructure for any type or kind of entity.

Ø  The ISA 62443:  More information can be found at this link:  https://en.wikipedia.org/wiki/IEC_62443

It too essentially spells out the needs for further software testing before it is released into the production environment.

Ø  The CISA:  In August of 2024, they created what is known as the “Software Acquisition Guide”.  More information about it can be seen at this link:  https://www.cisa.gov/resources-tools/resources/software-acquisition-guide-government-enterprise-consumers-software-assurance-cyber-supply-chain.

They also heavily recommend that businesses participate and agree to their “Software by Design Pledge”.  More details on it can be seen at this link:  https://www.cisa.gov/securebydesign/pledge

3)     A sense of sharing:

There is no person that is entirely responsible for making sure that the Software Development Lifecycle (also known as the “SDLC”) has been carried properly.  It is the responsibility of both the primary entity and any outside third parties that they may have decided to use to create a particular kind of software package.  In other words, if a catastrophe does happen, everybody needs to assume their sense of responsibility and ownership for what exactly happened.

My Thoughts on This:

Here are some other thoughts that I have about this as well:

Ø  Testing for security holes and vulnerabilities simply cannot wait at the very end of the SDLC.  It must be  addressed at the very beginning, even with the project requirements and milestones being drawn up.

Ø  All entities, no matter what industry they belong to, must adopt a Change Management Policy.  This is where a version history of all the changes to the SDLC are noted, documented, and archived for later use.  It is also equally important to have a Change Management Committee.  This is where a selected individual from each committee participates in this entire process, especially if it impacts the entire company.

How To Get Precious Cyber Funding From The C-Suite: 4 Golden Tips

 

As I have written about many times before, it is especially important for a business today to conduct a thorough Risk Assessment to see where their vulnerabilities lie in, and from there, see which ones are the most prone to security breach.  After that, you will then want to deploy the appropriate controls to mitigate the chances of any future threat variant from impacting them.

Although this is far easier said than done, there is also one factor that I have failed to take into consideration:  The money involved.  There will be a cost to deploy these controls, and if you don’t have the money in your present budget, then you will obviously have to prepare a new one and to present it to C-Suite to get the new funds approved.

But buying them buy in may not be so as you think.  Unfortunately, to many of them, addressing Cybersecurity Risks is an exceptionally low priority on the totem pole, as they don’t see that as a revenue generating opportunity.  Rather, they see that beefing up the lines of defenses as one huge expense. 

But what they fail to realize is that the steps taken today, while there might some costs now, will save them from losing their business if they are hit, especially with a Ransomware Attack.

So, one of the best ways in which you can secure any future funding is to calculate what your true “Vulnerability Debt” is, so that the risks of not addressing them can be fully quantified.  But first, it can be technically defined as follows:

“Vulnerability debt is the number of security risks that accumulate over time when they are not patched.”

(SOURCE:  Vulnerability Debt: Estimating the Impact)

A good example of this is the total number of applications that you have which have not been patched.  Simply look back to when they were all upgraded, and the last critical patch that was applied. 

Whatever the total accumulation is collectively then becomes what is known as your “Vulnerability Debt”.  Therefore, you will want to take the time  you need to do this, so that you can present an effective measure to C-Suite, thereby convincing them that extra money is really needed.

Here are some tips on how to do this:

1)     Risk Assessment:

Once again, do this critical task.  By doing so, you will have an inventory of all your digital assets.  But the key thing to remember here is that this is not a one-time deal.  Rather, it must be done on a regular basis, at least once a quarter.  But also keep in mind that you can automate parts of this process, by making use of Generative AI.

2)     Not All Is Equal:

There is no doubt that all your digital assets are important, but not all of them can be treated equally, at least at the outset (though the goal is to address all of them for the long term).  Therefore, as also stated before, you will want to rank those digital assets that are the most critical to maintain the mission critical operations.  Then from there, assign a Vulnerability Score to this group, and those that have a high ranking will need to get first attention.  For example, if you have 100 digital assets, and 20 of them are mission critical, then you will want to rank the latter based upon how prone they are to a threat variant.  Out of these 20, if 5 have the highest degree, then this will be on the top of your list.  One key benefit of doing this is that by presenting an entire laundry list of items to the C-Suite, you will have a much narrower one. From there, this will be much more comprehensible, and thus you can get into a lot more detail as to why the money is needed for these 5 digital assets.

3)     All  Are Needed:

In the end, doing all of this should not fall onto the shoulders of the just the CISO and their IT Security team.  Rather, it takes each employee to make this kind of thing work, and teamwork is greatly needed.  This must be stressed, and one of the net benefits of all this is that a strong level of Cyber Hygiene will also be realized, thus fortifying your lines of defenses even more.

4)     Don’t Forget the Metrics:

To help quantify your Vulnerability Debt, you will also want to include some relevant metrics.  The two biggest ones are the Meant Time to Detect (MTTD) and the Mean Time to Respond (MTTR).  These represent how long it takes an IT Security team to pick up that at threat variant is lurking in the IT and Network Infrastructure, and the latter represents how long it will take to contain it.  You should present two scenarios here:

Ø  What the MTTD and MTTR be if funding is not received for those 5 digital assets?

Ø  What the MTTD and the MTTR will be if funding is received for those 5 digital assets.

My Thoughts on This:

Well, there you have it, some tips on how to strengthen your need for Cybersecurity funding.  But remember, don’t paint to the C-Suite a complicated Cyber Threat Landscape, just tell them what is out there and what will happen if it is not done.  Also, you will also want to remind them of the extremely harsh financial penalties for non-compliance with the data privacy laws. 

That enough should get them interested.

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.