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
What Government Can (And Can’t) Do About Cybersecurity
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 2
Dr.T
Dr.T,
User Rank: Ninja
1/22/2015 | 4:17:50 PM
Re: Security Facts Labeling
There should always be checks and balances for anything we do, otherwise we are sure it will go out of control.
Dr.T
Dr.T,
User Rank: Ninja
1/22/2015 | 4:16:01 PM
Not about codebase
 

I think security is less about lines of codes but more about what technology we use and what standards we apply for secure application development practices. Sometimes more code may mean more security measures. Some of the old systems listed in infographics do not have any security around themselves.
gmerriman112
gmerriman112,
User Rank: Strategist
1/22/2015 | 3:42:36 PM
Re: Security Facts Labeling
 planetlevel says:

"I fear that the government approach will be to try to force the issue with super-compliance, liability, and audit.  That won't fix the culture and will probably make things worse, as  people will try to put the responsibility for security on the auditor."

I used to work in the building trades. While building and fire codes can be a real PITA, I believe that they definitely save lives and prevent injury and property damage.

Professional opinion is that, had the Port Authority been obligated to conform to New York City fire and building codes, the structures would probably not have collapsed completely and a lot more people would have made it out alive. Unfortunately, as a state agency, the Port Authority was exempt from local codes.

It seems to me that any entity holding personal information on the public that could lead to harm if divulged should have a fiduciary obligation to keep that information secure.
planetlevel
planetlevel,
User Rank: Author
1/22/2015 | 2:58:36 PM
Re: Security Facts Labeling
Sure, everyone could get hit by a submarine.  But it's not responsible to take crazy risks, particularly when you are entrusted with other people's data. Trying to figure out the reporting structure that will cure a company's security issues is too simple.  I like your lifestyle analogy here -- security is a culture problem for an organization.

For the nation as a whole, we need to think about how we instill the culture of security into our companies and agencies -- the ones creating the technology without enough security.  I fear that the government approach will be to try to force the issue with super-compliance, liability, and audit.  That won't fix the culture and will probably make things worse, as  people will try to put the responsibility for security on the auditor.

--Jeff
planetlevel
planetlevel,
User Rank: Author
1/22/2015 | 2:51:07 PM
Re: The internet needs a security makeover
I agree, but at least they're talking about cybersecurity now.  Now to help them not make things worse.
gmerriman112
gmerriman112,
User Rank: Strategist
1/22/2015 | 1:05:27 PM
The internet needs a security makeover
It seems to me the root problem here is that we have built an intrinsically insecure edifice that needs a serious structural overhaul. Anything short of that is simply fiddling around at the edges. I see nothing in these proposals that address the real problem.
GonzSTL
GonzSTL,
User Rank: Ninja
1/22/2015 | 12:04:25 PM
Re: Security Facts Labeling
"And CISO's should not report to CIO's.. Information security is a business problem, NOT an IT problem.  IT and security have different goals at the end of the day.  It has to provide a service to the business with no promise of security.  Security is provide a secure means for this IT enablement, which may not be the shortest path between two points."

You won't believe how many times I have said that and how many times people try to convince me otherwise. I have talked to many CIOs and a lot of them believe that Security should fall under their purview. They are convinced that if IT and Security are their responsibility, then they will be able to make wise decisions that fulfill both needs. Apparently, they fail to see a need for a separation of duties to prevent a conflict of interest from making a decision that will be a serious detriment to security. In their minds, they are able to make an impartial judgment that reaches a reasonable compromise that will be good for the organization. As I see it, IT is pressured to deliver technology that enables an organization to fulfill its goals, and security is tasked with the responsibility that the technology delivered is secure. When push comes to shove, which do you think will come out on top if the CIO is pressured to deliver technology? I have seen CIOs divert resources AWAY from security in order to facilitate IT delivery. We all know that security resources are scarce and have to be fought for tooth and nail. When the CIO performs that action, exactly how secure does that leave the organization? In a tie between IT and Security, the tie breaker must be someone that is above both IT and Security, and not someone who IS both IT and Security. It must be someone whose responsibility is the organization itself and not some subset of it.
Marilyn Cohodas
Marilyn Cohodas,
User Rank: Strategist
1/22/2015 | 10:58:03 AM
Security Facts Labeling
Great post Jeff. And for anyone wondering what a  "Security Facts" label might look like, here's an example courtesy of the author! 



 
<<   <   Page 2 / 2


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
The 10 Most Impactful Types of Vulnerabilities for Enterprises Today
Managing system vulnerabilities is one of the old est - and most frustrating - security challenges that enterprise defenders face. Every software application and hardware device ships with intrinsic flaws - flaws that, if critical enough, attackers can exploit from anywhere in the world. It's crucial that defenders take stock of what areas of the tech stack have the most emerging, and critical, vulnerabilities they must manage. It's not just zero day vulnerabilities. Consider that CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilitlies in widely used applications that are "actively exploited," and most of them are flaws that were discovered several years ago and have been fixed. There are also emerging vulnerabilities in 5G networks, cloud infrastructure, Edge applications, and firmwares to consider.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2023-1142
PUBLISHED: 2023-03-27
In Delta Electronics InfraSuite Device Master versions prior to 1.0.5, an attacker could use URL decoding to retrieve system files, credentials, and bypass authentication resulting in privilege escalation.
CVE-2023-1143
PUBLISHED: 2023-03-27
In Delta Electronics InfraSuite Device Master versions prior to 1.0.5, an attacker could use Lua scripts, which could allow an attacker to remotely execute arbitrary code.
CVE-2023-1144
PUBLISHED: 2023-03-27
Delta Electronics InfraSuite Device Master versions prior to 1.0.5 contains an improper access control vulnerability in which an attacker can use the Device-Gateway service and bypass authorization, which could result in privilege escalation.
CVE-2023-1145
PUBLISHED: 2023-03-27
Delta Electronics InfraSuite Device Master versions prior to 1.0.5 are affected by a deserialization vulnerability targeting the Device-DataCollect service, which could allow deserialization of requests prior to authentication, resulting in remote code execution.
CVE-2023-1655
PUBLISHED: 2023-03-27
Heap-based Buffer Overflow in GitHub repository gpac/gpac prior to 2.4.0.