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
How To Create A Risk 'Pain Chart'
Oldest First  |  Newest First  |  Threaded View
RyanSepe
RyanSepe,
User Rank: Ninja
8/29/2014 | 2:38:49 PM
Providing relatable value
This is great! For years now, Information Security has been progressing to the point where we can display extreme value to the business side of the operation. Not that we were irrelevant in the past, but I feel that we are getting the the point where non-security people can easily relate as to why security measures are so important.

In years to come I feel that this exercise will be quite prevalent and most likely already be ingrained in the minds of business owners. Educative repetition and relation analysis is the key.
JeremiahT680
JeremiahT680,
User Rank: Apprentice
9/1/2014 | 12:28:28 PM
Sandboxing data inside an encrypted application layer
If you sandbox each record or entity within and create an interface in your own coding language the perhaps you could create so many layers or barriers to cross that the intrusion would be detected and prevented.
Stratustician
Stratustician,
User Rank: Moderator
9/2/2014 | 9:09:50 AM
Re: Providing relatable value
I agree, I especially love the idea of assigning a risk or impact value to each specifically since as pointed out, some assets have more value than others.  Treating all risks as the same threat level is no longer a way to ensure that you are prioritizing the right areas of your security plan.  It's also a great way, as illustrated in the article, to ask for the funding you really need for each project based on the real risks and costs associated to protect those assets.
Marilyn Cohodas
Marilyn Cohodas,
User Rank: Strategist
9/2/2014 | 9:50:14 AM
Re: Providing relatable value
Concept sounds great to me, but who woud the decisionmakers be in determining risk/pain priorities? Thoughts anyone?  
RyanSepe
RyanSepe,
User Rank: Ninja
9/2/2014 | 2:06:47 PM
Re: Providing relatable value
I would think that everyone on a security team would have the ability to determine what has a higher risk value than others. Its a group effort. However, you need an authoritative head to sign off on these decisions. I would say the person who signs off on corporate security policy would be the authoratative head here. Most likely the CSO/CISO. 

I think a good way to look at this principle is you wouldn't construct a $1000 fence to guard a $10 asset. Realistic safeguards need to be a priority.
GonzSTL
GonzSTL,
User Rank: Ninja
9/3/2014 | 11:40:31 AM
Re: Providing relatable value
This is classic Risk Management, and is nothing new. I believe that the ultimate sign off should lie in the hands of someone responsible for the entire organization, such as the CEO, COO, CRO, etc. As long as the proper personnel are involved in the risk assessment team, the security officer makes recommendations based on a well informed decision process conducted by the team. Mind you, the assumption is that the risk assessment is conducted properly. If the security office is empowered to make the decision, then certainly the officer has the final say, with the implied consent of the CEO through delegation of authority.
JasonSachowski
JasonSachowski,
User Rank: Author
9/3/2014 | 11:50:07 AM
Re: How To Create A Risk 'Pain Chart'
@MarilynCohodas, everything security always comes back to the business it supports which would be no different with determining risk/pain priorities.  A "committee" of decisison makers should be made up of people who can translate the techie-talk into meanful business language and consists of stakeholders throughout the organization (ex. InfoSec, Privacy, Legal, etc), shareholders, and executives.


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-23896
PUBLISHED: 2022-06-28
Admidio 4.1.2 version is affected by stored cross-site scripting (XSS).
CVE-2022-29519
PUBLISHED: 2022-06-28
Cleartext transmission of sensitive information vulnerability exists in STARDOM FCN Controller and FCJ Controller R1.01 to R4.31, which may allow an adjacent attacker to login the affected products and alter device configuration settings or tamper with device firmware.
CVE-2022-30707
PUBLISHED: 2022-06-28
Violation of secure design principles exists in the communication of CAMS for HIS. Affected products and versions are CENTUM series where LHS4800 is installed (CENTUM CS 3000 and CENTUM CS 3000 Small R3.08.10 to R3.09.00), CENTUM series where CAMS function is used (CENTUM VP, CENTUM VP Small, and CE...
CVE-2022-30997
PUBLISHED: 2022-06-28
Use of hard-coded credentials vulnerability exists in STARDOM FCN Controller and FCJ Controller R4.10 to R4.31, which may allow an attacker with an administrative privilege to read/change configuration settings or update the controller with tampered firmware.
CVE-2022-34750
PUBLISHED: 2022-06-28
An issue was discovered in MediaWiki through 1.38.1. The lemma length of a Wikibase lexeme is currently capped at a thousand characters. Unfortunately, this length is not validated, allowing much larger lexemes to be created, which introduces various denial-of-service attack vectors within the Wikib...