Ransomware attacks have boomed during the last few years, becoming a preferred method for cybercriminals to get monetary profit by encrypting victim information and requiring a ransom to get the information back. The primary ransomware target has always been information. When a victim has no backup of that information, he panics, forced to pay for its return.
(more…)
What I’m writing here isn’t about whether you should be in the cloud or not. That’s a complex question, it’s highly dependent on your business, and experts could still disagree even after seeing all of the inputs
What I want to talk about is two distinct considerations when looking at the risk of moving your entire company to the cloud. There are many companies doing this, especially in the Bay Area. CRM, HR, Email—it’s all cloud, and the number of cloud vendors totals in the hundreds, perhaps even thousands.
We’re pretty familiar with one type of risk, which is that between the internet and the cloud vendor. That list of risks looks something like this:
The list goes on from there.
But the side of that cloud/vendor risk that companies don’t seem to be as aware of is their own insider access: while one risk is that the vendor does something stupid with your data, another is that your own employees do the same.
Considerations around insider access are numerous:
The situation in so many cloud-based companies is that they enable business by providing access to these cloud systems, but they don’t control which endpoints can reach that data. Users may get in through web apps, mobile apps, or other means. It’s application-based authentication that doesn’t know (or care) what type of device is being used: a 12-year-old desktop with XP on it, or an old Android device that hasn’t been updated in months or years.
Even worse is the false sense of security gained from spending millions on firewall infrastructure, while a massive percentage of the workforce either doesn’t work at the office or doesn’t hairpin back into the office through a VPN. The modern workforce—especially in these types of environments—increasingly connects from a laptop at home (or at a co-work site or coffee shop) directly to the backend, which is the cloud.
This puts us increasingly in a situation where most of the NetSec products we’ve been investing in for the last 15 years are moot, for the simple reason that fewer and fewer people are using the corporate network.
For cloud-based companies especially, it’s time to start thinking about AuthZ and AuthN from not just the user and app perspective, but from a complete endpoint perspective. What is the device, OS, patch levels, malware controls, etc., combined with the user auth, for any given access to an application and the data within?
The risk from a compromised vendor is significant, but it’s also largely outside of a company’s control. Anyone who’s been in security for a while knows that there are thousands of companies with X, Y, or Z certifications, or positive audit results when they absolutely shouldn’t have passed. It’s really hard to know how safe your data is when it’s sitting with hundreds of cloud vendors.
What you can do is to get better control over what your own people are doing with that same data, and that starts with understanding who’s accessing it, and from what devices.
With WannaCry and now Petya we’re beginning to see how and why the new strain of ransomware worms are evolving and growing far more effective than previous versions.
I think there are 3 main factors: Propagation, Payload, and Payment.*
WannaCry vs. Petya
WannaCry used SMB as its main spreading mechanism, and its payment infrastructure lacked the ability to scale. It also had a kill switch, which was famously triggered and halted further propagation.
Petya on the other hand appears to be much more effective at spreading since it’s using both EternalBlue and credential sharing
/ PSEXEC to infect more systems. This means it can harvest working credentials and spread even if the new targets aren’t vulnerable to an exploit.
[NOTE: This is early analysis so some details could turn out to be different as we learn more.]
What remains to be seen is how effective the payload and payment infrastructures are on this one. It’s one thing to encrypt files, but it’s something else entirely to decrypt them.
The other important unknown at this point is if Petya is standalone or a component of a more elaborate attack. Is what we’re seeing now intended to be a compelling distraction?
There’s been some reports indicating these exploits were utilized by a sophisticated threat actor against the same targets prior to WannaCry. So it’s possible that WannaCry was poorly designed on purpose. Either way, we’re advising clients to investigate if there is any evidence of a more strategic use of these tools in the weeks leading up to Petya hitting.
*Note: I’m sure there are many more thorough ways to analyze the efficacy of worms. These are just three that came to mind while reading about Petya and thinking about it compared to WannaCry.
They’ll probably respond, “Of course.”
Now ask them what you can do with that API.
“Oh, it’s a great API. You can do pretty much everything.”
“Great. How many people have access?”
“It’s super popular. We give access to all our developers, and any account can ask for and receive a key.”
“Cool. So how many of those keys are out there, and how do you control them?”
“…”
Exactly.
API keys often have full access to the platform, and guess what the access method is: a string of characters for your key, and a string of characters for your secret.
Sound familiar? How is this different from a username and password?
“Oh, but this is different because it’s all code-ey and stuff. Lots of programming and hard things.”
No.
That’s not a defense. Good APIs also share something else: great documentation.
It’s easy to do things like adding users, adjusting permissions, or pulling data using this interface because it’s meant to be easy. In fact, the easier it is to do something powerful, the better.
And this is all happening on 2FA-enabled accounts, despite that supposed higher level of security.
Summary
2FA is great. Enable it where you can. But it’s not the end of the conversation. Be sure to look at your API as well. Know what you can do with it, know who has keys, know how often they expire, and have a plan for monitoring and response.
For all intents and purposes, you should treat API access like legacy username and password access. After all, API keys and secrets are credentials.
Credentials can be stolen, and credentials can be used to do bad things.
This post is adapted from Daniel Miessler’s original blog post, which you can find at https://danielmiessler.com/blog/apis-2fas-achilles-heel/.
In the wake of WannaCry and other recent events, everyone from the Department of Homeland Security to my grandmother is recommending penetration tests as a silver bullet to prevent falling victim to the next cyberattack. But a penetration test is not a silver bullet, nor is it universally what is needed for improving the security posture of an organization. There are several key factors to consider. So I thought it might be good to review the difference between a penetration test and a vulnerability assessment since this is a routine source of confusion in the market. In fact, I’d venture to say that while there is a lot of good that comes from a penetration test, what people actually more often need is a vulnerability assessment.
Vulnerability Assessments are designed to yield a prioritized list of vulnerabilities and are generally best for organizations that understand they are not where they want to be in terms of security. The customer already knows they have issues and need help identifying and prioritizing them.
With a vulnerability assessment, the more issues identified the better, so naturally, a white box approach should be embraced when possible. The most important deliverable of the assessment is a prioritized list of vulnerabilities identified (and often information on how best to remediate).
Penetration Tests are designed to achieve a specific, attacker-simulated goal and should be requested by organizations that are already at their desired security posture. A typical goal could be to access the contents of the prized customer database on the internal network or to modify a record in an HR system.
The deliverable for a penetration test is a report on how security was breached in order to reach the agreed-upon goal (and often information on how best to remediate).
No organization has an unlimited budget for security. Every security dollar spent is a trade-off. For organizations that do not have a highly developed security program in place, vulnerability assessments will provide better value in terms of knowing where you need to improve your security posture even though pen tests are generally a less expensive option. A pen test is great when you know what you are looking for or want to test whether a remediation is working and has solved a particular vulnerability.
Here is a quick chart to help determine what your organization may need.
|
VULNERABILITY ASSESSMENT
|
PENETRATION TEST
|
|
|
Organizational Security Program Maturity Level
|
Low to Medium. Usually requested by organizations that already know they have issues, and need help getting started.
|
High. The organization believes their defenses to be strong, and wants to test that assertion.
|
|
Goal
|
Attain a prioritized list of vulnerabilities in the environment so that remediation can occur.
|
Determine whether a mature security posture can withstand an intrusion attempt from an advanced attacker with a specific goal.
|
|
Focus
|
Breadth over depth.
|
Depth overbreadth.
|
Most security programs benefit from utilizing some combination of security techniques. These can include any number of tasks, including penetration tests, vulnerability assessments, bug bounties, white/grey/black testing, code review, and/or red/blue/purple team exercises.
We’ll peel back the different tools and how you might use them in a future post. Until then, take a look at your needs and make sure the steps you take in the wake of WannaCry and other security incidents are more than just reacting to the crisis of the week.
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.