If you're in this boat, don't jump overboard. Often, existing tools found within the organization can help. For example, while many infosec programs are in their infancies, many disaster-recovery efforts are mature. Asking the disaster-recovery folks what they discovered during their business impact analysis studies can often provide security personnel with a much needed jump-start in identifying critical assets at a high level.
Again, business participation is critical, because neither IT nor security can be expected to understand all of an organization's dynamics. Finally, consider using third-party resources to help in the classification process, particularly if your organization is short staffed or there are concerns about business units objectively performing the task without aid or supervision.
If we were to apply the average infosec strategy to the world of physical security found at, say, a bank, we would wind up with a large building equipped with titanium reinforced doors. However, those doors would remain ajar, and burglar alarms would squawk at every tenth customer. Inside would be tables piled high with cash, appropriately marked "please do not touch." Finally, the lights would be off most of the time to ensure that security guards remained only moderately effective at protecting the piles.
This scenario sounds absurd, but the harsh reality is that the digital world doesn't stray far from this model. Most security efforts are perimeter-centric, lack robust internal controls and are not monitored sufficiently. But just as bank security has evolved to include controls on both the perimeters (using strong doors and walls), and internally (safes), shouldn't other organizations protect their digital assets similarly?
While most organizations do employ some internal controls, such as authentication mechanisms, file-access-control lists and the occasional network-segregation effort, the effectiveness of these controls is often lacking. Traditional internal controls are becoming less effective; modern-day attack methods usually exploit some type of application or OS flaw--flaws that let intruders bypass other protection mechanisms undetected.
For example, a basic Sun Solaris system may use proper file-level access controls in addition to strong authentication mechanisms, but if further precautions have not been taken, last week's RPC (remote procedure call) service vulnerability will let a remote attacker walk onto the machine as root, essentially turning over the keys to that machine's kingdom (and data).
To realize the benefits of cloud-native software, an application must actually be cloud-native—designed to run in the cloud, interacting with disaggregated cloud services, fully manageable as code—to deliver the expected benefits.
By combining resources and expertise, the AI-Enabled ICT Workforce Consortium will offer a blueprint for how industries can adapt to an AI-dominated future.
IT leaders should heed the guidance of cybersecurity insurance providers who think businesses should prioritize security education, incident preparedness, regular internal audits, and ongoing vulnerability scanning and patching.
