STE WILLIAMS

Emotet Made Up 61% of Malicious Payloads in Q1

The botnet has displaced credential stealers, stand-alone downloaders, and RATs in the overall threat landscape.

Emotet, a form of malware previously classified as a banking Trojan but now considered a botnet, made up 61% of all payloads in the first quarter of 2019, Proofpoint researchers report.

The data comes from Proofpoint’s “Q1 2019 Threat Report.” Researchers who have been tracking Emotet’s evolution say its popularity is reflected in the growth of attacks using malicious URLs. In the first quarter of 2019, emailed cyberattacks using bad links outnumbered those packing malicious attachments by five to one — up 180% from the first quarter of 2019, they report.

“The massive shift in Emotet’s prevalence and classification highlights just how quickly cybercriminals are adapting new tools and techniques across attack types in search for the largest payday,” says Sherrod DeGrippo, senior director of threat research and detection at Proofproint. Indeed, Emotet’s operators added more capabilities earlier this year as they continued to build Emotet from a Trojan meant to lift banking data to a threat delivering data-stealing payloads.

Emotet frequently downloads additional modules for sending spam and downloading additional malware. This caused a change in classification, as well as increases in the volume of messages trying to install Emotet. As a result, researchers saw a significant change in the volume of messages by malware family: 61% of payloads were botnets, and all of them were Emotet. The threat is responsible for the inclusion of the “botnet” category in 2019, during which Emotet has displaced credential stealers, stand-alone downloaders, and remote access Trojans (RATs) in the threat landscape.

Volumes of downloaders, stealers, and RATs fell 11, 8, and 7 percentage points, respectively, as Emotet jumped 26%. The widely distributed threat is available in malware-as-a-service form, meaning attackers can use it to distribute malware and leverage a wide network of infected devices. Emotet has been seen delivering a range of secondary payloads, including banking Trojans, but it’s not yet clear if this will have a broader impact on the malware market.

Banking Trojans made up 21% of malicious payloads in the first quarter of 2019, mostly driven by IcedID, The Trick, Qbot, and Ursnif. Emotet’s shift away from banking caused the banking Trojan count to fall. Combined with Emotet, the two comprised 82% of email-borne malware.

Emotet’s rise aside, researchers report the engineering, automotive, and education industries are most frequently targeted with email fraud. Across all industries, targeted businesses were hit with an average of 47 emailed attacks. While lower than record highs were seen in the fourth quarter of 2018, this could be a sign that attackers are becoming more selective. “Payment” was the top subject line in email fraud attacks, up 6 percentage points from the previous quarter.

Related Content:

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance Technology, where she covered financial … View Full Bio

Article source: https://www.darkreading.com/endpoint/emotet-made-up-61--of-malicious-payloads-in-q1/d/d-id/1334823?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Two weeks after Microsoft warned of Windows RDP worms, a million internet-facing boxes still vulnerable

The critical Windows Remote Desktop flaw that emerged this month may have set the stage for the worst malware attack in years.

The vulnerability, designated CVE-2019-0708 and dubbed BlueKeep, can be exploited by miscreants to execute malicious code and install malware on vulnerable machines without the need for any user authentication: a hacker simply has to be able to reach the box across the internet or network in order to commandeer it.

It is said to be a “wormable” security hole because it is possible to write a worm that spreads automatically, infecting a machine and then attacking others. Two weeks ago, Microsoft released security patches for systems going back to Windows XP to kill off this bug, and everyone is urged to install them.

So, a fortnight on, how many vulnerable internet-facing machines are still out there, waiting to be attacked and hijacked? Rob Graham of Errata Security claimed today he has already found nearly one million unpatched boxes exposed on the internet.

Specifically, Graham said he was able to, over the course of a few hours, find some 932,671 public-facing computers still vulnerable to CVE-2019-0708. To do this, he scanned the public internet for machines that had the Windows Remote Desktop network port (3389) open, using his masscan tool, and against those 7,629,102 matching machines, he ran a second script that sniffed out whether each box was running a vulnerable version of the service.

Some 932,671 were found running vulnerable Windows RDP services, 1,414,793 systems were patched, 1,235,448 were protected by additional CredSSP/NLA security checks, 82,836 were found to be running HTTP servers on port 3389 and thus not vulnerable, and the rest either timed out or the connection failed in some way.

Vulnerable

“The upshot is that these tests confirm that roughly 950,000 machines are on the public internet that are vulnerable to this bug,” Graham said. “Hackers are likely to figure out a robust exploit in the next month or two and cause havoc with these machines.”

Graham said such havoc could be on par with the destruction caused in 2017 by the outbreak of the WannaCry and NotPetya ransomware infections. With hackers already working on automated exploits (tools to scan for at-risk machines on networks have been released), a worm could easily get into the hundreds of thousands of exposed machines.

Password

Your specialist subject? The bleedin’ obvious… Feds warn of RDP woe

READ MORE

What’s worse is that a lot of organizations will probably have some forgotten vulnerable RDP-enabled machine facing the internet with working domain admin credentials stored on it, which can be stolen by Remote Desktop hackers and worms to further infiltrate networks. Graham told The Register that such a situation – domain admin credentials lifted from a compromised box – is tragically all too common in corporate environments these days.

“Most businesses have this problem,” Graham said. “They do a poor job of restricting domain administrator privileges.”

This tallying up of vulnerable systems should serve as a reminder to admins to make sure all of their machines are patched and up to date: these hundreds of thousands of vulnerable public-facing boxes are lucrative sitting ducks, and you do not want to be targeted by the next big worm. Graham recommends administrators run scans on their networks to check if any internet-facing boxes have been overlooked when installing May’s Patch Tuesday security fixes.

Not everyone patches, and for all sorts of reasons, though the outcome is usually the same. For instance, the US city of Baltimore’s systems were this month pwned by ransomware that apparently exploited a Windows vulnerability we’ve known about since 2017, when patches first emerged for it, to infect computers. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/05/28/windows_rdp_attack_scan/

Contain yourself, Docker: Race-condition bug puts host machines at risk… sometimes, ish

A vulnerability in all versions of Docker can be potentially exploited by miscreants to escape containers’ security protections, and read and write data on host machines, possibly leading to code execution.

This is according to senior SUSE software engineer Aleksa Sarai, who said the flaw is a race condition bug in which a file path is changed after it has been checked as valid, and, crucially, before it is used. The flaw, designated CVE-2018-15664, can be, in certain circumstances, abused to read and write arbitrary files on the host with root permissions from within a container, Sarai explained on Tuesday. This is possible provided there are no file system restrictions on the Docker daemon, such as those imposed by AppArmor.

And the most likeliest attack scenario requires a miscreant to be active within a container when a host administrator runs docker cp to copy data in or out of the container, at which point the attacker strikes to alter the underlying host file system. Not really an emergency, and more of an annoyance.

At the heart of the vulnerability is a function called FollowSymlinkInScope, which is used by Docker to resolve file paths. What Sarai found was that, in the case of docker cp, the paths could be modified using a symlink within the container to instead alter data on the host file system.

“If an attacker can add a symlink component to the path after the resolution but before it is operated on, then you could end up resolving the symlink path component on the host as root,” Sarai told The Register. “An example might be some cloud management service which allows users to copy configuration files into containers (or to read files from within a container.)”

Though Sarai’s disclosure focuses on docker cp, he noted that the root cause of the issue goes much deeper.

“The core flaw here is that there is an assumption that a path inside a container can be safely cleaned up to be as-is by a privileged process,” he explained, “and any Docker endpoint which touches FollowSymlinkInScope might be vulnerable.”

Docker CEO Steve Singh, Dockercon 19

Docker made itself popular with devs. Now it has to make itself essential for biz. But how? Ah ha! Pay-as-you-go enterprise features

READ MORE

To demonstrate the vulnerability in action, Sarai crafted a set of proof-of-concept scripts that show how the flaw can potentially be exploited from within a container to change files on the host machine. Sarai notified Docker’s security team privately of the hole ahead of this week’s public disclosure.

The PoC only works around one per cent of the time (race conditions are notoriously hard to recreate), but with repeated attempts, Sarai said, it can be reliably performed in around 10 seconds, most of the time.

Thus far, the bug hunter noted, there is no official fix available, and Docker has not said when a patch may be out. The company declined to comment. Sarai went public with the bug after the Docker security team agreed it would be better to alert customers while a patch is developed.

“The most complete solution to this problem would be to modify chrootarchive so that all of the archive operations occur with the root as the container rootfs (and not the parent directory, which is what causes the vulnerability since the parent is attacker-controlled),” said Sarai in his suggested solution.

“Unfortunately, changes to this core piece of Docker are almost impossible (the TarUntar interface has many copies and reimplementations that would all need to be modified to be able to handle a new ‘root’ argument).

“So, we instead settle for the next-best option which is to pause the container during our usage of the filesystem. This is far from an ideal solution (you can image some attack scenarios such as shared volume mounts) where this is ineffectual but it does block the most basic attack.”

Thus, so far, the proposed fix would be to pause containers during file operations, though that is unsatisfactory. Another short-term mitigation would be to disable docker cp. Sarai plans to continue to work on fixing the bug from within Linux.

“In an attempt to come up with a better solution for this problem, I’ve been working on some Linux kernel patches which add the ability to safely resolve paths from within a rootfs,” the engineer added. “But they are still being reviewed and it will take a while for userspace to be able to take advantage of the new interfaces.” ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/05/29/docker_race_condition/

FireEye Buys Verodin for $250 Million

Acquisition of security instrumentation firm will add more than $70 million to 2020 billing, FireEye estimates.

FireEye today announced that it has purchased security instrumentation vendor Verodin for $250 million in cash and stock.

Verodin’s Security Instrumentation Platform monitors, tests, and validates security controls of an organization’s network, identifying misconfigurations as well as other potential security weaknesses and the impact of newly emerging threats.

“Security effort does not equal security effectiveness. That is why security-conscious customers red-team their networks — they need the unvarnished truth of how effective their security programs are. Verodin gives us the ability to automate security effectiveness testing using the sophisticated attacks we spend hundreds of thousands of hours responding to, and provides a systematic, quantifiable, and continuous approach to security program validation,” said Kevin Mandia, CEO of FireEye.

“We believe there is no better way to train people and instrument better security than by continually attacking the environment and adapting security controls to the real threats,” Mandia said. “Finally, organizations will have a reliable and consistent way to quantify cyber risk in a manner understandable to frontline technicians and in the Board room.”

The acquisition is expected to increase FireEye’s billings by $20 million this year, and by $70 million in 2020, according to the company.

Read more about the deal here.

 

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/analytics/fireeye-buys-verodin-for-$250-million/d/d-id/1334821?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

GandCrab Gets a SQL Update

A new attack is found that uses MySQL as part of the attack chain in a GandCrab ransomware infection.

A new type of attack by the pervasive GandCrab ransomware could open the door to more juicy targets — database servers.

Researchers at Sophos Labs discovered a new attack using GandCrab against one of its honeypots. The attack entered the system through Port 3306/tcp — the default port for SQL database servers.

The attack targets MySQL databases via SQL commands to install a helper DLL, upload a series of small files, and ultimately employ SQL commands to upload and install the GandCrab ransomware payload to the database server.

“The origin of the attack is pretty clear; the fact that a server admin may not be monitoring a database server for what other things it might be doing (aside from hosting a database) is part of the problem here. Servers are not really ‘set it and forget it’ devices and this is why,” says Sophos principal researcher Andrew Brandt.

Attacks targeting a SQL server are neither new nor particularly novel — Brandt has written about other such attacks in the past. One of the unusual aspects of this attack is the way in which the attack calls its software from a server with a purported US location — and at least some software with a user interface written in simplified Chinese.

It’s notable that the attack uses the MySQL server but isn’t necessarily aimed at that server. “I see no evidence that the attackers care about what’s in the actual database, or any sign that they are attempting to manipulate or even trying to determine what data is on the machine prior to conducting this type of attack,” says Brandt.

But the honeypot where the attack was first seen doesn’t have a rich dataset ripe for exploitation, either, he notes.

“The honeypot’s ‘server’ isn’t really a server and it isn’t really ‘infected’ – the honeypot allows the SQL commands to execute and download the executable, but does nothing with it except store a local copy,” Brandt explains. Within that limitation, he says that he’s not positive that there is a real distinction between the server being used as a tool in the attack and the server being the target of that attack.

GandCrab’s licensing model makes it useful for criminals of varying sophistication levels, and this attack mechanism could use a similar model to become popular.

“Once the attack has been designed (and presumably, tested to work out the bugs), we see attacks such as this one used repeatedly, with little to no variation over time,” Brandt says. “The automation required to send out these kinds of attacks, once they’ve been engineered, is not particularly sophisticated at all.”

As for protection against the attack, Brand says using a non-standard SQL port might slow down port-scanning operations, and the real protection comes from using strong, unique passwords for root accounts and admin accounts, as well as a VPN for any application that needs a direct connection to the database server.

Related Content:

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and … View Full Bio

Article source: https://www.darkreading.com/application-security/gandcrab-gets-a-sql-update/d/d-id/1334824?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

FirstAm Leak Highlights Importance of Verifying the Basics

The Fortune 500 giant in the real estate industry missed a basic vulnerability in its website, leaving as many as 885 million sensitive records accessible to attackers. The fix: teaching developers the top 10 security issues and frequent testing.

A simple-to-exploit vulnerability in the website of real estate insurance giant First American Financial that could have resulted in the theft of hundreds of millions of sensitive records underscores the importance of verifying basic security measures and implementing secure programming practices, experts said this week.

The vulnerability, first reported by cybersecurity journalist Brian Krebs, allowed anyone with a valid link to a document on the site to increment the identifier to access the next document in sequence, as processed by the firm. The journalist found that the first record accessible through the site, document 000000075, dated back to 2003.

The basic error is a major misstep for the financial firm. The class of vulnerability is so well known that it had its own slot on the popular Open Web Application Security Project (OWASP) Top 10 list of web security vulnerabilities, “A4-Insecure Direct Object References,” for four years, and is so easy to find that a simple Google search often turns up the issue.

“You don’t need a sophisticated security solution to find these issues,” says Greg Pollock, vice president of products for cloud-security firm UpGuard. “It’s not about bulking up on cutting-edge DevOps or continuous integration testing, but back-to-basics engineering practices and having a culture that, if an engineer sees something wrong — and they should have seen something wrong here — they raise the issue and it gets fixed.”

Beyond the Top 10
The incident underscores that while many security firms urge customers to “go beyond the OWASP Top 10,” a large portion of companies still need to make sure their software developers, application security specialists, and operations teams are meeting basic hurdles. The problem is that developers who do not consider the security implications in the design of their software application may look at a database of millions of records and decide to just index them using a sequential code and, worse, expose that code through the URL in a web application.

“[Y]ou should never expose direct references to your data,” Jeff Williams, chief technology officer for Contrast Security, said in a statement on the incident. “Instead, you should always use an indirect reference that only allows access to authorized resources. This takes a bit of extra work, but this is a mandatory part of any internet web application or API.”

While there is currently no evidence that anyone accessed the data, the information held by First American is a treasure trove for financial fraudsters and identity thieves. First American is a title insurance company, a critical supplier of information used during the process of selling and buying homes. Title insurance companies collect information from both the buyer and the seller in a real estate transaction, verifying and taking custody of a great deal of sensitive information.

Among the documents that could be accessed through the website were bank account statements, mortgage records, tax information, Social Security numbers, driver’s license images, and receipt of money transfers, according to Krebs.

First American acknowledged the vulnerability, calling it “a reported design defect that created the potential for unauthorized access to customer data” in a statement released on May 28.

“We deeply regret the concern this defect has caused,” Dennis J. Gilmore, CEO at First American Financial, said in the statement. “We are thoroughly investigating this matter and are fully committed to protecting the security, privacy and confidentiality of the information entrusted to us by our customers.”

A real estate developer originally found the issue and reached out to freelance cybersecurity journalist Krebs, who verified the security flaw and contacted First American. After the company had fixed the issue, Krebs published his report.

Although the latest version of the OWASP Top 10, published in 2017, no longer has a category named for the specific class of vulnerabilities, insecure direct object references are one of the two categories that make up a new entry in the top 10 list known as “A5-Broken Access Control.”

“Access control weaknesses are common due to the lack of automated detection, and lack of effective functional testing by application developers,” OWASP states on its site, adding: “Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of the limits of the user.”

Two years ago, most companies had to worry about denial-of-service attacks on their web applications. Today, a wide variety of access control issues dominate the list of cloud security issues, according to the SANS Institute’s annual survey. Account or credential hijacking is the top issue, followed by misconfiguration, privileged user abuse, unauthorized application components, and insecure APIs or interfaces, according to the SANS Institute’s “2019 State of Cloud Security” report.

Developers need to be knowledgeable about such common issues and create tests to check code for any errors that could undermine security, UpGuard’s Pollock says.

“While it is trivial to iterate through and pull out as many documents as you want, the flip side of it — and again why this one has gone undetected so long — is that it is much harder to do mass scans for these direct object references,” he says. “Companies need to be mindful that this is a problem [and] have some sort of penetration testing or dynamic testing that looks for data leaks.”

Related Content

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT’s Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline … View Full Bio

Article source: https://www.darkreading.com/attacks-breaches/firstam-leak-highlights-importance-of-verifying-the-basics/d/d-id/1334825?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Millions of Canva users’ data stolen as GnosticPlayers strikes again

Is it true that most people only read the first four lines of email, as this Twitterer suggests?

If so, a cynic might assume, as did IT consultant Dave Hall, that the marketing department at a company that’s just suffered a massive data breach likely know that… and, hence, shoehorn in their own message at the top of the first breach notification they sent out.

The first breach notification sent out by Canva – the Sydney-based company behind the eponymous online design tool – let recipients know that on Friday 24 May 2019, it had discovered a breach while it was still in progress.

As soon as we were notified we immediately took steps to identify and remedy the cause and have reported the situation to authorities (including the FBI). We are very sorry for any concern or inconvenience this may cause.

… that is, Canva notified users that it had discovered a breach… after it told them about 1 million new free images and a new tool for printing t-shirts, that is.

A breach notice sent out later that same day was stripped of what Hall called “marketing crap.”

The breach

Canva didn’t mention how many records had been accessed but said that it involved users’ names and email addresses, along with passwords that had been salted and hashed with Bcrypt: a password-hashing function that’s considered to be secure.

This means that our user passwords remain unreadable by external parties.

ZDNet had more details: the hacker reportedly told the publication that he/she/they got away with data for roughly 139 million users. Since February 2019, the hacker(s), who goes by the alias GnosticPlayers, has listed for sale on the dark web a total of 932 million users’ data, stolen from 33 companies worldwide, according to ZDNet.

More stuff stolen

GnosticPlayers said that on 24 May, they’d downloaded everything up to 17 May 2019, and that Canva had detected the breach and closed down its database server.

Besides the stolen data types that Canva notified users about, the breach also involved real names and, where available, customers’ city and country information. There were 61 million hashed passwords stolen, as well.

Another breached data type was Google tokens – the tokens that enables users to sign up for the site without setting a password. ZDNet reports that out of the total 139 million affected users, 78 million of them had Gmail addresses associated with their Canva account. The dump included details for some of the site’s staff and admins, according to the 18,816-account slice the hacker shared.

Canva said in a statement that users’ credentials haven’t been compromised, as far as it can tell, but that for safety’s sake, users are being advised to reset their passwords:

We securely store all of our passwords using the highest standards (individually salted and hashed with bcrypt) and have no evidence that any of our users’ credentials have been compromised. As a safeguard, we are encouraging our community to change their passwords as a precaution.

Busy, bad beavers

GnosticPlayers was in the headlines in March 2019, when the hacker(s) put up 26 million records for sale, stolen from six online companies. As we reported then, the first of what would turn out to be four data caches had gone up for sale in early February, when GnosticPlayers were trying to sell a database of 617 million records pilfered from 16 companies for $20,000.

Days later, Gnosticplayers added 127 million records stolen from eight websites, before adding a third round on 17 February comprising another 93 million from another eight sites.

 

What to do

Users should take Canva’s advice and change their passwords as soon as possible. If two-factor authentication (2FA) is offered, turn it on.

And if you work in a marketing department, please, don’t tuck important details about a security breach underneath marketing messages that could lead users astray. It’s difficult to take companies’ professed commitments to “protecting the data and privacy of all our users” and to “open, transparent communication that puts our communities’ needs first” when the first thing a recipient sees in a breach notification is a marketing spiel.

Transparency and commitment to data protection mean prioritizing the real meat of the message, not tucking it underneath fluff. Canva deserves credit for fixing this in its second notification, but who knows how many users didn’t read about their jeopardized data because their eyeballs glazed over in reaction to what came off as marketing spam?

 

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/S_e8BRAjRak/

Germany mulls giving end-to-end chat app encryption das boot: Law requiring decrypted plain-text is in the works

Government officials in Germany are reportedly mulling a law to force chat app providers to hand over end-to-end encrypted conversations in plain text on demand.

According to Der Spiegel this month, the Euro nation’s Ministry of the Interior wants a new set of rules that would require operators of services like WhatsApp, Signal, Apple iMessage, and Telegram to cough up plain-text records of people’s private enciphered chats to authorities that obtain a court order.

This would expand German law, which right now only allows communications to be gathered from a suspect’s device itself, to also include the companies providing encrypted chat services and software. True and strong end-to-end encrypted conversations can only be decrypted by those participating in the discussion, so the proposed rules would require app makers to deliberately knacker or backdoor their code in order to comply. Those changes would be needed to allow them to collect messages passing through their systems and decrypt them on demand.

Up until now, German police have opted not to bother with trying to decrypt the contents of messages in transit, opting instead to simply seize and break into the device itself, where the messages are typically stored in plain text.

America

WHY can’t Silicon Valley create breakable non-breakable encryption, cry US politicians

READ MORE

The new rules are set to be discussed by the members of the interior ministry in an upcoming June conference, and are likely to face stiff opposition not only on privacy grounds, but also in regards to the technical feasibility of the requirements.

Spokespeople for Facebook-owned WhatsApp, and Threema, makers of encrypted messaging software, were not available to comment.

The rules are the latest in an ongoing global feud between the developers of secure messaging apps and the governments. The apps, designed in part to let citizens, journalists, and activists communicate secured from the prying eyes of oppressive government regimes.

The governments, meanwhile, say that the apps also provide a safe haven for criminals and terror groups that want to plan attacks and illegal activities, making it harder for intelligence and police agencies to perform vital monitoring tasks.

The app developers note that even if governments do try to implement mandatory decryption (aka backdoor) capabilities, actually getting those tools to work properly, without opening up a massive new security hole in the platforms that miscreants and criminals could exploit, would be next to impossible. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/05/28/german_government_encryption/

‘Cattle, Not Pets’ & the Rise of Security-as-Code

Nearly a decade in, the famous analogy has underpinned a sea change in enterprise IT, but still falls short of the security mark. More recent developments can help.

In 2011, Randy Bias, a prominent member of the cloud community, used the phrase “cattle, not pets” as an analogy for how DevOps engineers should think about the cloud and the benefits of managing infrastructure in a cloud-native environment. The phrase “cattle, not pets” (attributed originally to Bill Baker, a Microsoft distinguished engineer encouraging his DBA audience to think differently about their SQL Server deployments) has become pervasive within the DevOps community and is a useful way to think about the difference between a dynamically scalable cloud deployment and a more static on-premises server rack. Once the description was applied to the cloud, it was adopted across the IT community, showing up in sources as varied as Amazon webinars and CERN presentations.

Although the concept has contributed to the cloud design principles of thousands of DevOps engineers across the industry, the analogy is imperfect. Treating servers as “cattle, not pets” without broader strategies to implement security eliminates concerns about resiliency and initial server configuration, leaving the proverbial door wide open for unanticipated access issues, malicious intrusion vectors, and other security threats and vulnerabilities that have been prevalent since well before the cloud concept was mainstream.

Enter the many different flavors of infrastructure-as-code. There are many ideas about planning for DevOps, and the benefits of the overall infrastructure-as-code movement: numerous papers on the “cattle, not pets” approach; dissertations on the broader notion of replicability, rigor, scrutiny, as well as inherent security that come from code-based implementations of infrastructure; sales briefs on the benefits of being able to model infrastructure changes without time-consuming and costly mock-ups in a manually configured staging environment; and so on.

The concept of using code-based policies to impose consistent security on a broader IT environment is not new in IT or the cloud. However, minimizing security risks with comprehensive security-as-code in a way that almost entirely removes the need for any manual interaction is a relatively new practice — as is the prioritization of security principles when DevOps teams consider how to configure code-based policies to manage their own environments.

This doesn’t mean the industry isn’t addressing the practice. Companies including Puppet, Chef, Red Hat, AWS, IBM, and many others offer rich tool sets that are intended to ease the transition from traditional IT practices and DevOps approaches to security in favor of the DevSecOps approach to infrastructure management — and DevSecOps appears to be on its way to becoming the new normal.

Opportunity for Change
The broader implications of the DevSecOps mindset for the governance of security and compliance have been relatively underappreciated until recently. The industry now has an opportunity to shift the focus of security and compliance scrutiny from the live environment to a code repository, greatly increasing the assurance possible in any security review and simplifying the methodology required by any external auditor tasked with verifying the compliance posture of a given environment. Prominent cloud providers are releasing verified reference architectures that, if implemented without any security-impacting changes, provide compliance with any number of prominent security and regulatory frameworks their customers may encounter. An entire cottage industry has formed around the idea that security can be written instead of implemented. While not as prominent as the overall infrastructure-as-code movement, comprehensive security-as-code could be truly transformative for organizations building in the cloud.

If done carefully, true security-as-code has many benefits. Budget-conscious executives can mandate code-based security policies to minimize the large amounts of time, money, and effort traditionally required to properly deploy and vet a mature security posture. System owners can remove the human from the loop in all but the most esoteric of management actions — minimizing the risk of some of the most prominent malicious intrusion vectors seen today and virtually guaranteeing consistent implementation of security controls and policies. Architects can mock up their selected controls, service-level agreement obligations, and performance targets without delay and quickly iterate through options before allocating any resources to a test deployment.

Companies working to bring software products to market in heavily regulated industries can reduce their time to compliance — even across multiple frameworks at once — as they are only limited by the speed at which their developers can type, instead of the long lead times traditionally expected between development, assessment, and remediation. Undermanned DevOps teams can confidently reuse and recycle security policies and assets between environments without worry about customization or loss of fidelity, easing the pain of frequent requests for segregated resources or low-level tenant-by-tenant isolation.

And finally, interested reviewers and external auditors can be confident when assessing the security assurance provided by a heavily automated and code-based IT environment. Focusing such a review on a code-based architecture implemented throughout the scope of a given review reduces the chance that, somewhere, in some far-off closet, sits a critical server still being treated as a pet.

Related Content:

Andrew Williams is the product director for the Cyber Risk Advisory and FedRAMP Assessment Services teams at Coalfire.  As product director, Andrew oversees Coalfire’s sales, delivery, and professional development strategy for all advisory and assessment personnel … View Full Bio

Article source: https://www.darkreading.com/cloud/cattle-not-pets-and-the-rise-of-security-as-code-/a/d-id/1334771?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

8 Ways to Authenticate Without Passwords

Passwordless authentication has a shot at becoming more ubiquitous in the next few years. We take a look at where things stand at the moment.PreviousNext

Image Source: Adobe Stock- Denys Prykhodov

Image Source: Adobe Stock- Denys Prykhodov

So are we finally doing this? Are we finally moving to passwordless authentication?

Microsoft and Google have been pushing this aggressively over the past several months, and Apple has been a major player by being the first out of the box with fingerprint authentication on the iPhone. Most PCs and Mac laptops now offer Touch ID, so inside of a year or two people can use them for passwordless authentication, too.

The industry largely views passwords as outdated and one of the major causes of breaches. According to the Verizon’s “2019 Data Breach Investigations Report,” more than 80% of breaches leverage stolen or weak passwords. That’s why the industry has been pushing for open standards, such as FIDO (Fast Identity Online), which would help security teams and developers more readily deploy passwordless authentication. 

In addition, recent research by Ant Allan, a Gartner analyst who focuses on passwordless authentication, predicts that by 2022, 60% of large and global enterprises and 90% of midsize enterprises will implement passwordless methods in more than 50% of use cases — up from 5% in 2018.

To be sure, vendors have taken notice. Here are eight of the leading passwordless authentication approaches and a look at what needs to happen moving forward.

 

Steve Zurier has more than 30 years of journalism and publishing experience, most of the last 24 of which were spent covering networking and security technology. Steve is based in Columbia, Md. View Full BioPreviousNext

Article source: https://www.darkreading.com/endpoint/authentication/8-ways-to-authenticate-without-passwords/d/d-id/1334809?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple