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.

USA Vs China: Who Will Win The Gen AI Battle?

 

With all the political turmoil that is happening today, the news headlines do not seem to be coming out as quickly about Generative AI as it once did, say, going until the end of last year.  The biggest fear is China, not just from the standpoint of tariffs, but also in terms of competition. 

In fact, if you recall, they came out with something remarkable like ChatGPT.  It was developed by a company called Deep Seek, and the cost of running the algorithms and the hardware needed (such as the GPUs) is much lower.

Also,  Nvidia took a decent hit with a financial charge of over $5  billion,  with the restrictions that have been put into place on sending GPUs to China.  But despite all this turmoil, there is yet another headwind that both produce and make use of Generative AI must contend with:  Data Privacy, and Compliance that comes along with it.

As I have written before, the fuel that runs Generative AI models are the datasets that are fed into it.  Not only do they need it to train, but they also need them to create the output you are seeking when you ask  it a specific query.  Generative AI Compliance will come across three different  angles:

Making sure that the right controls have been implemented on the training datasets.

The same with the above, but for the output that has been generated.

Also, the same with the above, but making sure that any data which is submitted by the end user  is  also as secure as possible.

To this end, the trends for this year are expected to be as follows:

1)     Efforts From The EU:

They have produced a new piece of legislation called the “NIS2”.  It is an acronym that stands for the “Network and Information Security”.  Just like the GDPR, it applies to any entities that conduct business in the EU, even if they are not physically located there. The tenets and the provisions are almost similar, but they also take a strong stance to Generative AI.  But, the financial penalties are very harsh for non-compliance:  It can be up to 2% of the revenue that has been generated on a global basis.

2)     The DORA:

This is an acronym that stands for the “Digital Operational Resilience Act”.  It was created and enacted by the EU as well.  But apart from Generative AI compliance, it has two key specific focuses:

Ø  Proving that you cannot just only create backups, but that you can also restore the mission critical data from them, if you are ever impacted by a disaster, natural or man-made.

Ø  That the backups which have been created are segregated in terms of the physical and logical ones.  The goal here is to make sure that businesses are storing their backups in various locations, such as On Premises or in the Cloud.

 

3)     More From China:

Take for example, that you have a hosting account with a domain registrar that is located here in the United States (such as GoDaddy, Namecheap),  etc.).  You decide to host your application in a datacenter that is in the US.  Although this may be technically correct once you launch your web application, the datasets that it uses could be stored at a datacenter in entirely different country that you may not even be aware of.  So, the hot topic of debate here is who takes custody of it?  Well, the Chinese Government is making this even clearer now, especially when  it comes to Generative  AI.  To this extent, they have passed two distinct laws:

Ø  The Personal Information Protection Law ( also known as the “PIPL”).

Ø  The Data Security Law ( also known  as the “DSL”).

Ø  The Cybersecurity Law (also known as the “CSL”). 

The result is that China is now relaxing its restrictions on storing “foreign datasets” on the datacenters that are located there and are now highly encouraging businesses from all  over the world to even put there backups as well. 

4)     The Rise of E2EE:

This is yet another acronym that stands for “End to End Encryption”.  Encryption has always been a favored tool in the arsenal to protect anything data related.  After all, it scrambles it so that if anything was to be intercepted by a third party, there is nothing  that they can do with it unless they have the appropriate key to decode it.  But with the E2EE, the IT Security team will have no choice on what can be encrypted, by default, everything will be.  While this is heavily targeted towards  the Generative AI algorithms and the datasets they use,  using the E2EE can be a bad thing as well.  For instance, even a Network or Database Administrator with the right permissions can be denied access.

My Thoughts on This:

On a theoretical level, all of this sounds great, taking more steps that the datasets that Generative AI use are now even more protected.  But in the real-world sense, just how enforceable is all of this?  Normally in a world where there is not much chaos or confusion, this all could very well be done.  But once again, given the political climate that we now have in the United States, who knows how this will all come together.

Then there is the issue of China.  They are the second largest economy in the world, and in fact, their manufacturing and supply chain logistics far surpass that of the United States.  For example, we are still trying finish construction on the next Ford class aircraft carrier, the “USS John F Kennedy”. 

During this time, the Chinese are already working on I believe, their third carrier, which would be quite compatible.

So, there are still many complexities and uncertainties which lie ahead because of these tariffs.  But one thing is for sure in this regard:  Given their sheer dominance, I bet they will far  outpace the United States when it comes to Generative AI development and production.  Not only can they do it faster and cheaper, but the quality  in the end may prove to far superior in the end.

The Top 4 Risks Of Outsourcing Gen AI To China

 

While there seems to be no end to the tariff war in China, many top CEOs are warning the Administration that there could very well be empty shelves in the major grocery stores, and other related goods stores here in the United States.  In fact, even the major shipping containers that are coming from China are now starting to slow down.

Because of this, many countries could very well be turning to China now to be the major trading partner, replacing the US entirely.  One such area in which this is happening is in the Generative AI Industry. We have already seen this with Nvidia, where severe restrictions are now being placed upon them onto the kinds of chips that they can export there.

But one area which people could very well turn to China is around actually developing the models that drive Generative AI.  After all, why pay more here in the US when you can have the same thing done there faster and cheaper (but of course, the quality of the development will still be an issue.

But there are inherent risks depending upon another country to do this.  Here are some of them:

1)     Biasness :

The technical definition of Generative AI biasness is:

“Artificial intelligence bias, or AI bias, refers to systematic discrimination embedded within AI systems that can reinforce existing biases, and amplify discrimination, prejudice, and stereotyping.”

(SOURCE :  https://www.sap.com/resources/what-is-ai-bias)

To put it in another way, this is when the out output that has been yielded by the model produces some kind of content that is deemed to biased, or even racial in some way.  Although this is a direct product of the datasets that have been fed into the model, a good Gen AI programmer could still tweak the algorithms, so that they can still produce this same kind of content, even though the data might have checked before time. 

2)     Optimization:

In the world of Generative AI, this is also known as “fine tuning”.  This is where you are trying to keep all the models in top condition so that they produce the best possible outputs.  Obviously, if you have created the model, you will know immediately how to do this.  But what if  you had outsourced the model creation to another company in China?  Obviously, they are not going to tell the secret sauce to their recipe, so fine tuning here could be a major problem, because you will not know the inner workings of the model.

3)     A Deepfake?

A Deepfake, as its name implies, is a “fake” version of a real person.  This is quite widely used during the political election seasons, where a Cyberattacker could post a fake video of a politician asking for donations to their respective campaign.  So, in this regard, how do you know that a Generative AI model that has been developed for you is not the real thing?  What if you are just getting a “Deepfake” of it.  This is an especially worrisome situation, since your customers will also be inputting data and information into the submittal forms of your web application.  This in turn will also be fed into your Gen AI Model, so that you can analyze any trends to help you determine the viability of new products and services.

4)     The Creation:

Whenever you hire an outside source to develop your Gen Models, you will also want to meet the team that will be doing, whether it is virtual or face to face.  Be very leery of hiring a company from overseas that does not introduce their team to you.  After all, it could be a Cyberattacker that is creating it and could put all kinds of covert backdoors into the code so that they can gain direct access to your IT and Network Infrastructure. 

My Thoughts on This:

The risks that I have described here can not only happen in China,  but it could even very well happen here in the US.  The key difference is that we contract in place that can be enforced in a court of law, though it may take some time. 

If you choose to outsource this to a company, say once again to China, and they violate the terms of the contract that they have signed with you, it will be very difficult best, if not impossible, to gain any kind of legal recourse.

So, while faster and cheaper might be the way to go, think twice about that.  Quality will always beat those two in the end, no matter what the need or the application is.

How To Plan Your Infrastructure as a Code Environment: 4 Point Checklist

 

There is one thing I don’t  think that I have ever written about before in a blog:  That is, “Infrastructure as a Code”, also known as “IaC” for short.  It is a term that is commonly thrown around the world of Cloud lingo, but many people do not really know what it is about.  In fact, as much as I have written about Cloud, I never really paid too much attention to it.

So, before we go any further, here is a technical definition of it:

“Infrastructure as Code (IaC) is the managing and provisioning of infrastructure through code instead of through manual processes.”

(SOURCE :  https://www.redhat.com/en/topics/automation/what-is-infrastructure-as-code-iac)

Although the intricacies behind it can be quite complex, long story short, it just gives you another way to manage your Cloud based deployment (whether it is in the AWS or Microsoft Azure), on an automated basis, using various programming languages, such as that of Python. 

But despite the tools that the Cloud providers give to manage your IaC environment, many businesses in Corporate America still fail in configuring it properly.

Consider some of these statistics:

*According  to the “2024 Security Report” from Check Point Software, 82% of businesses failed to properly configure their IaC environment.

*Back in 2022, because of a misconfiguration, the ICICI Bank leaked out well over 3.6 million files.

To see the detailed report that was published by Check Point Software, click on the link below:

http://cyberresources.solutions/blogs/2024-Cloud-Security-Report-CheckPoint.pdf

So, if you decide to make use of an IaC environment to help run your Cloud deployment, here are a few key tips to keep in mind:

1)     Plan:

The first thing that you need to do is map out exactly what you want  the IaC environment to do, but even more importantly, you need to take into sincere consideration the security issues that are involved, such as:

Ø  Defining the functional and controls requirements.

 

Ø  The kind of Cloud environment that you want to have, for example, Private Cloud, Public Cloud, Hybrid Cloud, etc.  and the security that goes along with all of that.

 

Ø  Use tools like Terraform or Cloud Formation to build out your IaC environment.

 

Ø  Create a backup strategy for your images that you create for your Cloud apps (such as Virtual Machines, Virtual Desktops, etc.).

 

2)     Software Development:

               The primary goal of the IaC environment is to use code libraries to build it out.  Since source   code creation is often forgotten about when it comes to security, keep the following in mind:

Ø  Create the appropriate rights, permissions, and privileges for everybody that is on the DevSecOps team.

 

Ø  Keep a version control of all software builds that go into the IaC environment.

 

Ø  Always test any Open-Source APIs that you may use in a sandboxed environment first.

 

Ø  Monitor your Privileged Access Management (PAM) environment very closely.

 

3)     Testing:

Before you put your IaC framework into the production environment, you should first evaluate it:

Ø  Assess each component of it in a sandboxed environment (as just discussed).

 

Ø  Make sure that the source code has been completely vetted of any gaps or vulnerabilities.  This can very often be done through Vulnerability Scanning or Penetration Testing.

 

In fact, according to the “2024 State of Cloud Security Report” by Orca, over 74%  of businesses failed to detect any issues with the Cloud deployments (as it relates to the IaC environment that was created).  To get more details on this, click on the link below:

 

http://cyberresources.solutions/blogs/2024-State-of-Cloud-Security-Report%20(1).pdf

 

4)     Deploy and Monitor:

After you have implemented your IaC framework into your Cloud based deployment, you now have made sure that it is running smoothly.  Here are some points in this regard:

Ø  Make use of SIEM to notify you on a real time basis of any abnormal network activity or behavior.

 

Ø  Try to make use of Generative AI to filter out for the False Positives.  This will help alleviate “Alert Fatigue” on your IT Security team.

 

Ø  Have a Change Management process in place for any updates or reconfigurations that you need to do for your IaC environment, and make sure that everything is well documented.

 

My Thoughts on This:

As Cloud technologies evolve over time, there is no way that you can keep track of everything on a manual basis.  You will need automation, and even lots of it.  This is where IaC will come in very useful.  But remember, it is also prone to Cyber Threat Variants, as the given how powerful the IaC is, it will soon become a prized target for the Cyberattacker.

Therefore, keep checking the controls that you have in place for them, and change/upgrade them as necessary.  Also, we will see IaC being used heavily in Edge Computing.  This is where all the data processing occurs in a location that is close to your device.  This helps to avoid any downtime or network latency when you need your datasets the most.