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
Ashley Madison CEO Resigns
Oldest First  |  Newest First  |  Threaded View
Joe Stanganelli
Joe Stanganelli,
User Rank: Ninja
8/28/2015 | 11:12:30 PM
C-suiters resigning
One of the main reasons we see C-suiters resigning in the wake of data breaches is because of pressure from politicians and regulatory authorities, who want to see that the company is doing *something*.  Firing/asking the C(x)O to resign is a good step in that direction because it's usually a far preferable action than being subject to heightened regulatory scrutiny and sanctions.
rlynxwiler617
rlynxwiler617,
User Rank: Apprentice
8/29/2015 | 12:34:57 PM
Re: C-suiters resigning
I wonder if it's not so much the gov't regulators as much as saving face with the public.  Maybe the perception is that if I lose the trust of the public because of a breach, I can regain some of that by punishing someone at the highest levels, someone who is more visible than a first line manager.  My experience is that regulators are more concerned with the nuts and bolts of control changes rather than some figure head getting fired.  Who knows.
jamieinmontreal
jamieinmontreal,
User Rank: Strategist
8/31/2015 | 9:51:44 AM
Re: C-suiters resigning
This is true, but the effect is then to force other CxOs to look at their organization's security posture and liability differently.   If the buck stops at the CEO's door for a data breach the trickle down effect should be to force tighter security across the organisation.

The Board, in deciding that releasing the CEO port-breach is tacitly agreeing that breach prevention is a strategic, executive level responsibility.   This is no bad thing.
SgS125
SgS125,
User Rank: Ninja
8/31/2015 | 11:42:18 AM
Re: C-suiters resigning
Or in some cases it's just a valid result of poor performance just like any other job.  There are consequesnces for not doing a good job at most employers, why should we treat the c level suite any different?
Joe Stanganelli
Joe Stanganelli,
User Rank: Ninja
8/31/2015 | 11:25:45 PM
Re: C-suiters resigning
On the one hand, I think your cause-and-effect analysis here is spot on.

On the other hand, there is a popular saying in the security community that I think holds true: "There are two types of organizations -- those that know they have been breached, and those that don't yet know they have been breached."

Which is to say that to a certain degree, hacks -- while mitigatable -- are not wholesale preventable.
rlynxwiler617
rlynxwiler617,
User Rank: Apprentice
9/1/2015 | 9:45:01 AM
Re: C-suiters resigning
Your two types of companies was exactly what i was thinking when i wrote my response.  If every company has been breached to some degree (and I believe most if not all have already been) then every CxO in the nation should be stepping down at some point in the next few months.  I don't think this individual would have stepped down except for the high media visibility (and, of course, their business purpose), which is why I'm proposing that public perception/press are undeniable factors in who steps down and who doesn't.
Joe Stanganelli
Joe Stanganelli,
User Rank: Ninja
9/4/2015 | 5:39:26 AM
Re: C-suiters resigning
Other pertinent factors, I think, include the breadth/depth of the breach, and the vulnerabilities (both technical and cultural) that contributed to the breach.

Another important factor: crisis response.  Adobe presents a great example of what not to do.  With their major breach a while back, the company first estimated that just under 3 million customers had been impacted.  They later amended that number to at least 38 million.  Eventually, it was revealed that more than 150 million customers' information was compromised.

Not good for business.


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
Developing and Testing an Effective Breach Response Plan
Whether or not a data breach is a disaster for the organization depends on the security team's response and that is based on how the team developed a breach response plan beforehand and if it was thoroughly tested. Inside this report, experts share how to: -understand the technical environment, -determine what types of incidents would trigger the plan, -know which stakeholders need to be notified and how to do so, -develop steps to contain the breach, collect evidence, and initiate recovery.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2022-46411
PUBLISHED: 2022-12-04
An issue was discovered in Veritas NetBackup Flex Scale through 3.0 and Access Appliance through 8.0.100. A default password is persisted after installation and may be discovered and used to escalate privileges.
CVE-2022-46412
PUBLISHED: 2022-12-04
An issue was discovered in Veritas NetBackup Flex Scale through 3.0. A non-privileged user may escape a restricted shell and execute privileged commands.
CVE-2022-46413
PUBLISHED: 2022-12-04
An issue was discovered in Veritas NetBackup Flex Scale through 3.0 and Access Appliance through 8.0.100. Authenticated remote command execution can occur via the management portal.
CVE-2022-46414
PUBLISHED: 2022-12-04
An issue was discovered in Veritas NetBackup Flex Scale through 3.0 and Access Appliance through 8.0.100. Unauthenticated remote command execution can occur via the management portal.
CVE-2022-44721
PUBLISHED: 2022-12-04
CrowdStrike Falcon 6.44.15806 allows an administrative attacker to uninstall Falcon Sensor, bypassing the intended protection mechanism in which uninstallation requires possessing a one-time token. (The sensor is managed at the kernel level.)