Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Database Security
Authentication
Mobile
Privacy
Compliance
Careers and People
Identity & Access Management
Security Monitoring
Advanced Threats
Insider Threats
Vulnerability Management
Comments
Deconstructing The Sony Hack: What I Know From Inside The Military
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
Jeff.schilling
50%
50%
Jeff.schilling,
 User Rank: Author
1/8/2015 | 3:23:31 PM
Re: REGIN
@Ryan,

I probably did sound contradictary in the comments you highlighted.  Great catch.  I did not do a good job in defining where I am talking about threat and where i am talking about data/applications.  

In the first reference, I was referring to Data and Applications.  In other words, you cannot protect all of your data and applications, you should aggressively segement and control access to your company crown jewels.  

In the second reference, I am referring to threat.  I am trying to coach CISO's and business owners to assume you are a target.  Too many companies, like CodeSpaces, probably believe they are not a target because they do not have something of value to criminals (i.e. Credit card data, Electronic Health Records).  Even in this case, these companies should still NOT try to protect their whole environment, especially if it is very complex or dynamic.  They should still identify the company crown jewels and aggressively segement.   In the use case of CodeSpaces, they might have been saved by 2 factor auth for their admin access to their cloud envrionment.   

Hopefully that clears up the confusion, thanks for asking for clarification.

 

  
Jeff.schilling
50%
50%
Jeff.schilling,
 User Rank: Author
1/8/2015 | 11:33:55 AM
Re: Ransomware and backups
As I mention in my article, the government could have some forms of intelligence that they can not share with the general public.  I am not going to speculate, but I have a good idea based on my experience of what it takes to truly get attribution.  It is kind of like triangluating your position on a map from reference points.  The more reference points you have, the greater accuracy you can plot your position.  

Bottom line, the more reference points in intelligence collection you have, the greater the accuracy you can predict attibution.  I will say that what has been released, to include the additional information that Director Comey release does not make that case to me.  But as he says, "If you could see what I see..." there maybe other forms of intel that does make the case.  The whole point of my article is to get security folks focused on the important facts and leave the attribution to the government and Sony.

 

 
RyanSepe
50%
50%
RyanSepe,
 User Rank: Ninja
1/8/2015 | 9:58:15 AM
Re: REGIN
@Jeff.

Could you elaborate on the following two statements; one was made in the article and the other was made in a post from you. The two seem to contradict each other.

 

Post- " I think some of the big companies should start changing their strategy from trying to protect everything, to protecting what is important and assuming everything else is potentially compromised."

 

Article-"Too much of the security industry is still focused on the data that you "have to protect" instead of protecting the entire organization. In today's cyberrisk environment, you cannot predict who the ransom actors will go after."


The only discrepancy I could find was that one elaborates to big organizations but the other is ambiguous to use case. Thanks!
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
 User Rank: Strategist
1/8/2015 | 9:36:29 AM
Re: Ransomware and backups
@Jeff, I wonder what your thougts are about the FBI comments that "Sloppy' North Korean backers gave themselves away...

 

 

Jeff.schilling
50%
50%
Jeff.schilling,
 User Rank: Author
1/7/2015 | 2:05:45 PM
Re: Ransomware and backups
Terry B,

For the CodeSpaces incident, the threat actors owned their corp network.  They sent ransome threats.  As the victim tried to clean up their infected network, the threat actors captured their log on creds for their customer environment, hosted by a cloud provider.  Once they had those log on creds, they locked the victim out of their own hosted cloud environment.  Sent another ransome threat.  When the company could not pay, the threat actors deleted their customer data (because they had admin creds), to include backups, in the hosted cloud environment.  

Root cause, No Multifactor auth for admin access by the victim to control their hosted environment, no security controls in their hosted environment, no way to recover deleted data and walk back what the threat actors had done.  

The real lesson here is you get what you pay for in security when you host in a cloud provider.  You have to secure that environment as vigiously as you would secure any of your data.  Most cloud companies make security an add on feature.  At FireHost, we are a secure cloud, our customers can't opt out of our security protection.
TerryB
50%
50%
TerryB,
 User Rank: Ninja
1/7/2015 | 1:36:38 PM
Ransomware and backups
Jeff, how did that ransomware attack put that hosted company out of business? Surely people are still making backup copies of their (hopefully) virtual servers and more timely copies of the data itself? I could see this causing a loss of some data, like from last backup. But to take them out of business completely? How is that possible?

Is there something about ransomware and backups I'm not understanding? What you describe would be major pain in rear end here while we rebuilt services and data. But knocking us out of business, I don't think so.

Actually I know so since our primary business server is an IBM i5 server which is not addressable from internet and can't be infected by someone clicking on rogue attachment/web page.

It is our infatuation with Windows type computers which run script and allow easy o/s corruption, combined with connecting directly to Internet for "customer services" which has put us all here. Anyone got stories of IBM mainframes being pawned like these Windows/Linux servers are? Besides an inside attack, of course. No system can survive that if the good guy decides to become a bad guy. You can only hope to stop them sooner rather than later in that case.
SgS125
50%
50%
SgS125,
 User Rank: Ninja
1/7/2015 | 12:14:28 PM
Re: REGIN
I suspect that since the Sony situation has overtaken the media and completly obfuscated the REGIN discovery we will not hear much more about it.  There were several fine technical analysis of the code and it's methods.  A seriously long read for anyone who cares to speculate on the methods and uses of this type of malware.

 

Let's hope that we and our networks we protect don't have anything interesting enough for the players that play to ruin our day.

 

Don't forget to hide your backups!  They can't encrypt or erase what they can't find.

 

 
Jeff.schilling
0%
100%
Jeff.schilling,
 User Rank: Author
1/7/2015 | 12:06:17 PM
Re: REGIN
Re: REGIN, no clear attribution has been assigned to this framework.  I doubt that it ever will be clearly attributed.  There are lots of sophisticated nation-state threat actors, I would not jump to any conclusions on who is holding the strings on that framework.

In the US, we have US Code Title 50 congressional legislation that limits foreign intelligence collection on US soil by the US Intelligence Community.  Any exceptions to this are adjudicated by the FISA court when the Intelligence Community can show that the data they want to collect on US soil is critical to putting the pieces together on other global collection efforts.  There have been some well-publicized cases where some folks believe the FISA court got the decision wrong, I am inclined to agree in some cases with those skeptics that the collection was an over reach.  However, I will offer that there is no other cyber super power that has this kind of oversight that keeps their intelligence collection limited to foreign collection only.  They might not get it right every time, but there is no systemic abuse that we should worry about.  I do not lose any sleep over this at all.

To clarify what keeps me up at night, threat actors had for the most part focused on Computer Network Exploitation.  Now they are more increasingly getting kinetic and destroying IT infrastructure, having a serious business impact.  Most large multinational organizations like Sony and many others have a very large surface area of attack due to the massive complexity associated with managing a global enterprise.  I think some of the big companies should start changing their strategy from trying to protect everything, to protecting what is important and assuming everything else is potentially compromised.

Thank you for your comments.  This is great dialogue.  

 
SgS125
100%
0%
SgS125,
 User Rank: Ninja
1/7/2015 | 11:07:04 AM
REGIN
Should we also wait to hear from the Government on what they had intended to do woth the REGIN attacks?

I agree that the "media" who ever you consider them to be, has it wrong, will always have it wrong, and can't understand enough of the situation to ever report anything other than what they are told to repeat.

If you are sleepless over this then you have already lost your battle.  It's always the next unknown threat that gets us, no point in worrying over it or asking for more money to protect you from things you don't know about or can't plan for.  

We can only hope that all the exploits that our "freinds" in Government hold secret will not be used against us.

 

 

 

 
Jeff.schilling
100%
0%
Jeff.schilling,
 User Rank: Author
1/7/2015 | 10:04:38 AM
Re: Commentary
That is an interesting theory and very plausable.  That would be what I would do as well to cause more confusion.
Page 1 / 2   >   >>


News
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Edge-DRsplash-10-edge-articles
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
News
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-25284
PUBLISHED: 2021-02-27
An issue was discovered in through SaltStack Salt before 3002.5. salt.modules.cmdmod can log credentials to the info or error log level.
CVE-2021-3144
PUBLISHED: 2021-02-27
In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)
CVE-2021-3148
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. Sending crafted web requests to the Salt API can result in salt.utils.thin.gen_thin() command injection because of different handling of single versus double quotes. This is related to salt/utils/thin.py.
CVE-2021-3151
PUBLISHED: 2021-02-27
i-doit before 1.16.0 is affected by Stored Cross-Site Scripting (XSS) issues that could allow remote authenticated attackers to inject arbitrary web script or HTML via C__MONITORING__CONFIG__TITLE, SM2__C__MONITORING__CONFIG__TITLE, C__MONITORING__CONFIG__PATH, SM2__C__MONITORING__CONFIG__PATH, C__M...
CVE-2021-3197
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. The salt-api's ssh client is vulnerable to a shell injection by including ProxyCommand in an argument, or via ssh_options provided in an API request.