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.

Comments
Who Cares Whos Behind A Data Breach?
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 3   >   >>
GonzSTL
GonzSTL,
User Rank: Ninja
2/24/2015 | 8:39:15 AM
Re: Motive
I realize that you are not discrediting attribution, as no serious security professional really would. I do agree with you that the early finger pointing thing can be an awful distraction. Unfortunately, media coverage puts as great an emphasis on this as they do on the breach itself, even to the point of sharing and sometimes leading the headline. As a society, this is what we have been accustomed to seek from the news. Bad news sells, and we want to know who the bad guys are. This is a serious distraction that can divert valuable resources towards the effort to discover who the perpetrators are, which of course detracts from the primary goals of the incident response team, particularly in smaller organizations. It can also lead to flawed incident response if improper assumptions are made based on the known modus operandi of the suspected intruder. A valid argument can be made that an initial attempt to identify the intruder can help analyze what happened in that the team can look for indicators of the attack, but it is better to leave this out of the public until after the investigation has been completed. Correct attribution however, is a small consolation after the fact, but unfortunately does not necessarily lead to successful prosecution of the attacker.
Kerstyn Clover
Kerstyn Clover,
User Rank: Moderator
2/23/2015 | 10:54:47 PM
Re: Motive
You're correct, and my intent wasn't to completely discredit attribution as a piece of maturing your incident response/security program internally. Just to put the emphasis on your "secondary" phrasing, and to perhaps try to push away from rapid finger-pointing in the initial days after an incident. When evidence is there and trustworthy the effort is certainly worth it; however, I've also encountered many cases where effort and resources are best focused on other things first and attribution later if at all.
Kerstyn Clover
Kerstyn Clover,
User Rank: Moderator
2/23/2015 | 10:44:03 PM
Re: Owning the consequences
You're spot on. One of the other things on my mind, but a bit out of my league to speak on is the idea of trying to wrap laws or legislation around these attacks if we do manage to pin down a source. Topic for someone else's blog, perhaps :)
Kerstyn Clover
Kerstyn Clover,
User Rank: Moderator
2/23/2015 | 10:42:08 PM
Re: Rod Sirling was right.
Oh, really? I've been slowly starting to watch the show but must not have come across that one yet. I'll be looking forward to it!
Kerstyn Clover
Kerstyn Clover,
User Rank: Moderator
2/23/2015 | 10:40:51 PM
Re: Motive
It certainly can be. As an internal process, it's important to look for indications of the origin of an attack if they're present and reliable. Especially if a certain actor is launching multiple attacks, correlation of these can start to paint a picture that helps to prepare for future attack attempts. My focus with this was really to discuss how much we tend to over-hype attribution, especially in the early moments after a breach and on the media. Pointing fingers preemptively and vocally isn't helpful, but you're right that it is certainly a piece of the puzzle in lessons-learned and maturing an incident response/defense program over time.
Marilyn Cohodas
Marilyn Cohodas,
User Rank: Strategist
2/23/2015 | 4:48:40 PM
Re: Motive
I would suspect that if you can identify who is responsble -- and make them accountable (e.g. disincent them frm doing doing it again) -- it would be extremely worth the effort. But that is the exception, not the rule, it would seem.
GangstaNerd
GangstaNerd,
User Rank: Apprentice
2/23/2015 | 1:49:33 PM
Re: Motive
The term "Prevention" never sits well with me because we all know we can only delay or deter attacks not prevent them.
Dr.T
Dr.T,
User Rank: Ninja
2/23/2015 | 12:28:14 PM
Re: Motive
I agree. That is how you build enough knowledge base to adapt to current environment and try to get ready for next set of waves for attacks. Without any experience you are actually in the dark and not knowing what to do even for simple preventive course of actions.
Dr.T
Dr.T,
User Rank: Ninja
2/23/2015 | 12:25:01 PM
Re: Motive
I agree, who need to know where it came from and what they of characteristics it has to be able to respond to similar future attacks.
Dr.T
Dr.T,
User Rank: Ninja
2/23/2015 | 12:22:51 PM
Re: Funny
Aliens most likely have no idea what cyberattack is. They mostly likely develop their services security in mind from group up and enjoying the life without any cyberattacks. :--))
<<   <   Page 2 / 3   >   >>


Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Improving Enterprise Cybersecurity With XDR
Enterprises are looking at eXtended Detection and Response technologies to improve their abilities to detect, and respond to, threats. While endpoint detection and response is not new to enterprise security, organizations have to improve network visibility, expand data collection and expand threat hunting capabilites if they want their XDR deployments to succeed. This issue of Tech Insights also includes: a market overview for XDR from Omdia, questions to ask before deploying XDR, and an XDR primer.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2022-31081
PUBLISHED: 2022-06-27
HTTP::Daemon is a simple http server class written in perl. Versions prior to 6.15 are subject to a vulnerability which could potentially be exploited to gain privileged access to APIs or poison intermediate caches. It is uncertain how large the risks are, most Perl based applications are served on ...
CVE-2022-31082
PUBLISHED: 2022-06-27
GLPI is a Free Asset and IT Management Software package, Data center management, ITIL Service Desk, licenses tracking and software auditing. glpi-inventory-plugin is a plugin for GLPI to handle inventory management. In affected versions a SQL injection can be made using package deployment tasks. Thi...
CVE-2022-31084
PUBLISHED: 2022-06-27
LDAP Account Manager (LAM) is a webfrontend for managing entries (e.g. users, groups, DHCP settings) stored in an LDAP directory. In versions prior to 8.0 There are cases where LAM instantiates objects from arbitrary classes. An attacker can inject the first constructor argument. This can lead to co...
CVE-2022-31085
PUBLISHED: 2022-06-27
LDAP Account Manager (LAM) is a webfrontend for managing entries (e.g. users, groups, DHCP settings) stored in an LDAP directory. In versions prior to 8.0 the session files include the LDAP user name and password in clear text if the PHP OpenSSL extension is not installed or encryption is disabled b...
CVE-2022-31086
PUBLISHED: 2022-06-27
LDAP Account Manager (LAM) is a webfrontend for managing entries (e.g. users, groups, DHCP settings) stored in an LDAP directory. In versions prior to 8.0 incorrect regular expressions allow to upload PHP scripts to config/templates/pdf. This vulnerability could lead to a Remote Code Execution if th...