<div dir="ltr"><a href="https://www.darkreading.com/cloud/7-modern-day-cybersecurity-realities/d/d-id/1340826">https://www.darkreading.com/cloud/7-modern-day-cybersecurity-realities/d/d-id/1340826</a><br><div><br></div><div>Move to the cloud. Shift left. Buy the latest XDR and deception tools. The technology and cybersecurity industry has always been susceptible to marketing hype, but do these moves actually make their organizations more secure? Or do they just add more complexity?<br><br>With all the major hacks, from SolarWinds to the issues with Microsoft Exchange, how can security pros sleep at night? They may think they are doing the right thing, but are they operating with a false sense of security?<br><br>Michael Isbitski, technology evangelist at Salt Security, says security pros have to focus more on securing the application programming interfaces (APIs) that power many of these tech strategies. From hosting internal cloud apps to relying on gateways and traditional patch management tools, the old methods don't focus enough on API security – and the APIs are susceptible to attackers.  <br><br>"With so much at stake, businesses need to humbly accept that they have been overly confident in these security approaches and tool choices," Isbitski says. "They should seek to update their tooling and processes accordingly to address modern threats."<br><br>We've compiled seven tips to help security pros sort out what they need to think about as they deploy many of these evolving security concepts and technologies.</div><div><br></div><div><br>Are the Cloud Apps You Build Really Secure?<br>As companies moved to the cloud, they invested heavily in security tooling reimagined for the cloud, often in the form of cloud workload protection and container security tools, says Salt Security's Isbitski. Such tools, he says, are useful for identifying known vulnerable dependencies, detecting misconfigurations, microsegmenting workloads, and preventing drift from hardened baselines. But unpatched vulnerabilities and misconfigurations in platforms such as Kubernetes have been a point of entry for attackers, allowing them to bypass access controls, run their own code on compromised clusters, and deploy cryptocurrency miners.<br><br>"Unfortunately, this new breed of cloud security tooling still fails to address much of application-layer security," Isbitski says. "These tools primarily address network security and infrastructure security and continue to leave applications vulnerable. So the public cloud may be secure, but that doesn't mean what you build in-house is secure."<br><br></div><div><br></div><div>Companies Can Shift Left but Still Must Shift Right<br>The shift-left mantra encourages development teams to push security process and tooling earlier into the software development life cycle (SDLC), as well as dispersing security subject matter expertise, says Salt Security's Isbitski. Shift left has strong ties to DevSecOps practices, which aim to integrate and automate security during design, build, and deploy phases. The practice has paid off for many organizations, as they can iterate on security more quickly, validate whether security was appropriately built in from the beginning, and reduce the cost of fixing vulnerabilities later in the SDLC.<br><br>However, organizations cannot entirely shift left at the expense of runtime security, Isbitski says. Developers will never write perfect code, they can't always scan the code extensively enough within release windows, and scanners by design are built to find known vulnerabilities or weaknesses that follow well-defined patterns.<br><br>Sandy Carielli, a principal analyst at Forrester who covers security, adds that shift left was never meant to mean only shift-left. However, on the plus side, she says shift left does let development teams find and remediate a large number of security flaws faster.<br><br>"New attacks and zero-days are always coming along, so we still also have to protect applications in production," Carielli says. "I don't think there are a lot of organizations that are shifting left to the exclusion of runtime security. Most people realize they need both."<br><br></div><div><br></div><div>WAFs and Gateways Won't Fully Secure APIs<br>APIs are the foundation of today's modern applications, but few organizations understand just how prominent they are or the level of risk they present, says Salt Security's Isbitski. APIs make up a disproportionate share of risk because they're such an attractive target for attackers, but too many organizations assume Web application firewalls (WAFs) and API gateways protect their APIs. These technologies cannot prevent most types of API attacks because of inherent design limitations, and they give organizations a false sense of security for their APIs and API-driven applications.<br><br>"APIs are unique to every organization, and real-world attacks against APIs don't often follow well-defined patterns of known vulnerabilities," Isbitski says. "Combatting these security risks requires runtime security that continuously learns API behaviors and stops attackers early regardless of the attack techniques used."<br><br>Rik Turner, principal analyst for emerging technologies at Omdia, agrees that security teams need to address API security beyond WAFs or API gateways.<br><br>"I recall in the mid-2010s having this discussion with another of our analysts who argued that the gateway vendors would step up to the need for additional security, and indeed at least one of them, Apigee, did launch an add-on module for security," Turner says. "However, API security is largely the preserve of a separate group of vendors and not the API gateway folks."<br><br>Forrester's Carielli adds that organizations expose a large number of applications, and hence a large amount of data, through APIs. She says stories of data leakage and unauthorized access are common. Carielli stresses that API security today consists of a combination of tools -- some runtime application security tools that have expanded to protect APIs, some API management tools that address certain security use cases, application security testing tools that can test APIs, and API-specific security tools.<br><br></div><div><br></div><div>Traditional Patch and Vulnerability Management Tools Won't Secure APIs<br>While patch and vulnerability management programs can help security teams address risks in off-the-shelf software and components, application and API security strategy requires more, says Salt Security's Isbitski.<br><br>But eager to avoid falling victim to the 99% of vulnerabilities that are known by security and IT pros, companies have put significant effort behind patch and vulnerability management. They are often tracked as common vulnerabilities and exposures (CVEs), a useful taxonomy for cataloging well-defined vulnerabilities in published software or released hardware. However, Isbitski says this can never capture the expanding universe of potential weaknesses that organizations can introduce as they build or integrate applications and APIs.<br><br>"Attackers will sometimes target well-known exploits in software, like in the case of the recent Exchange server hack," he says. "Much more common, though, attackers look for weaknesses in APIs or API integrations that are unique to the target organization. There are no 'patches' for code that the organization has created or integrations that engineers will use to stitch together applications and APIs."<br><br>Common weakness enumeration (CWE) IDs are a more appropriate classification to describe issues in homegrown applications and APIs, Isbitski says. If the organization develops its own code or integrates with other code, then security professionals should get familiar with CWEs and the OWASP Top 10, he adds. They are more relevant classifications when building applications or APIs rather than sourcing software from somewhere else where CVE IDs are applicable.<br><br>According to <a href="http://cwe.mitre.org">cwe.mitre.org</a>, CWEs helps developers and security practitioners do the following:<br>- Describe and discuss software and hardware weaknesses in a common language.<br>- Check for weaknesses in existing software and hardware products.<br>- Evaluate coverage of tools targeting these weaknesses.<br>- Leverage a common baseline standard for weakness identification, mitigation, and prevention efforts.<br>- Prevent software and hardware vulnerabilities prior to deployment.<br></div><div><br></div><div><br></div><div>Basic Awareness Training Falls Way Short -- Especially For Engineers</div><div><br></div><div>A great deal of attention has been put into security training around ransomware attacks, phishing, and social engineering since these are common techniques employed by attackers.<br><br>Maxine Holt, senior research director for security at Omdia, says companies make far too many assumptions regarding the extent to which this kind of awareness training actually changes behavior. Too many organizations take a tick-box approach, she says, delivering the training typically from a third party once or twice a year, ensuring employees have done this training, and then forgetting about it until it is due again.<br><br>"It's woefully inadequate and, quite frankly, a waste of time," Holt says. "It would be significantly better to focus on point-in-time security training that changes the behavior of employees so that they think in a more security-positive way."<br><br>Training and awareness focused on application security still lag behind at many companies, adds Salt Security's Isbitski. Developers and engineers have minimal time for training as application release trains have accelerated. If they do find time to learn, they will focus on their technology stack of choice and security becomes mostly an afterthought.<br><br>"Security expertise continues to be in short supply for most organizations, particularly when it comes to 'full stack' engineering," Isbitski says. "This leaves nonsecurity personnel with minimal guidance as they create or update applications. Compressed development and release timelines that result from agile methodologies and DevOps practices leave little time for secure design reviews or threat modeling exercises where security training and awareness could bear fruit."<br><br>Lack of time is always a challenge, Holt says, but security must shift left in the development life cycle; it can't remain an afterthought, adding that from an organizational perspective, why not build security in up front?<br><br>"This is so much cheaper than remediation after a security incident or breach," Holt says. "But this does require commitment to allow for training and time for developers to learn, as well as the desire from the developers to do so. It's not an overnight fix."<br><br></div><div><br></div><div>Just Buying a New Tool Doesn't Make the Company Secure<br>Companies like to think that once they buy the latest hot security tool, the organization is secure, but that's just not the case, says Peter Firstbrook, a research vice president at Gartner who covers security.<br><br>Companies have a very hard time holding on to good people, he says, so quite often the new tools companies buy are managed improperly and the admins misconfigure them. Security teams need to ask: Are we on the latest version? Are we using all the capabilities of the new product? Do some of the rules get overwritten during updates?<br><br>"People think they can buy their way out their security problems," Firstbrook says. "Unfortunately, in a lot of situations, the people who installed the product in the first place are long gone. That's why in some situations there may be 1,000 rules and the people managing the operation are afraid to change them. They're afraid they will take out something important."<br><br>Companies also need people with soft-side skills -- people who can follow procedures, read the documentation, and communicate what's wrong to management, he says.<br><br>According to Eric Parizo, principal analyst for security operations at Omdia, people also think that all these new products will come fully integrated. That's one of the reasons extended detection and response (XDR) has emerged, as it's essentially a preintegrated solution encompassing threat detection and response across endpoints, networks, and clouds, he says.<br><br>"But it's a big challenge any way you slice it," Parizo says. "That's also a reason why managed security services continue to grow to the point that even the top-tier vendors are increasingly offering managed services. They recognize that no matter how integrated and effective their product platforms may be, there's an increasing number of CISOs who are looking to outsource management of as much technology as possible. I think that's a trend that's likely to grow steadily over time."<br><br></div><div><br></div><div>Companies Rolling Out IoT Products Don't Always Focus on Security<br>A company's focus may be on building cars, consumer electronic products, or household appliances, but they don't always realize that they have to invest a bit more time and money into the development and management of the code that goes into these products or the mobile apps that integrate with them, says Salt Security's Isbitski.<br><br>"It's really been the evolution of computing," he says. "Companies that weren't in the business of software creation now find themselves developing applications and APIs to enable their core business. Organizations don't always realize that with many IoT devices they have to secure the APIs as well as the app."<br><br>Omdia's Parizo adds that what Isbitski refers to encompasses many of the issues around the Internet of Things (IoT). As 5G becomes more pervasive in the US and across much of the developed world, ubiquitous connectivity for all sorts of IoT devices will become not only possible, but standard practice, he says. And many of those devices not only don't have security capabilities built in, but they also weren't developed with security in mind.<br><br>"As a result I think without better protection for IoT over 5G, we're going to see a massive comeback of IoT botnets, especially as botnet-driven cryptomining has become increasingly lucrative for many adversaries," Parizo says. "I think IoT will be one of the cybersecurity stories of the coming decade."<br><br></div></div>