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 Cant) Do About Cybersecurity
Threaded  |  Newest First  |  Oldest First
Marilyn Cohodas
100%
0%
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! 



 
Dr.T
100%
0%
Dr.T,
User Rank: Ninja
1/22/2015 | 4:23:50 PM
Re: Security Facts Labeling
It is really impressive that injection is still at the top of the list. That is not really default to solve. I guess old legacy system are not easy to change and becoming the target.
planetlevel
100%
0%
planetlevel,
User Rank: Author
1/22/2015 | 5:27:19 PM
Re: Security Facts Labeling
"Impressive" isn't exactly the word I would have chosen :-)  But I get your point.  That's why I spend all my waking time building tools to help stamp out these vulnerabilities.
GonzSTL
50%
50%
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.
gmerriman112
50%
50%
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.
planetlevel
50%
50%
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.
Dr.T
100%
0%
Dr.T,
User Rank: Ninja
1/22/2015 | 4:19:54 PM
Re: The internet needs a security makeover
Not only that but also a new mindset around security. We can not make internet secure, we need to start with that and try to find out a new approaches to address current security needs.
planetlevel
50%
50%
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
gmerriman112
100%
0%
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.
Dr.T
100%
0%
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.
planetlevel
100%
0%
planetlevel,
User Rank: Author
1/22/2015 | 5:34:25 PM
Re: Security Facts Labeling
Right on.  We need to look to models like building codes, FDA inspections, labels, material safety data sheets, etc...  to help fix the failures in the software market.  Right now, software buyers and users don't have nearly enough information about the software they are forced to use.  Yet they have to trust it with their personal information, money, health, etc...   Fixing this "market for lemons" means ensuring that everyone has the same information about the trustworthiness of software.  Only then can market forces encourage secure apps.
Dr.T
100%
0%
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.
planetlevel
50%
50%
planetlevel,
User Rank: Author
1/22/2015 | 5:31:21 PM
Re: Not about codebase
The infographic is just a reminder that the size, complexity, interconnection, and criticality of our applications is continuously increasing.  All of those make security more difficult, but in combination they make a perfect storm for attackers.  We have to up our game, because the bad guys clearly are.
LarchOye
100%
0%
LarchOye,
User Rank: Apprentice
1/23/2015 | 8:04:04 AM
"PROSECUTION"...
  1. Allow prosecutors to pursue anyone related to a hacking incident under Federal RICO statute. Given the difficulty of accurately identifying suspects, gathering evidence, and proving relationships in cyberspace, this approach seems ripe for abuse. There's nothing wrong with aggressively pursuing cyber criminals, but we can't forget about due process. How easy would it be to frame someone as a hacker if all that is required is a loose association? What if I friend the wrong person on Facebook or LinkedIn?

 

This really makes me feel obliged to bring up what is probably *THE* most important point dealing with the subject of cyber-prosection:

1) There is absolutely NO WAY to prove whether or not ANY piece of Digital or Electronic 'Evidence' used by the prosecution *ISN'T FABRICATED*.  This important factoid means that there is an ENORMOUS shadow of a doubt cast over every 'cyber-case'...  Since the For-Profit Prison Industry in this country CLEARLY constitutes a CONFLICT OF INTEREST with the American public; and certainly with the pursuit of "Justice".
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
1/25/2015 | 7:51:58 PM
CFAA
*sigh* Unfortunately, the CFAA needs revamping before it needs strengthening/broadening, because it in and of itself hurts cybersecurity efforts by penalizing independent security research.
jleon570
50%
50%
jleon570,
User Rank: Apprentice
1/26/2015 | 12:46:59 PM
Problematic solutions at best.
It seems to me that "raising the bar for developers" isn't practical for the very reasons you cited as the reasons: the staggering complexity.

The number of "developers" in the world is too large to be hogtied.  Perhaps you could coerce developers over a certain size in terms of revenue or installations and by doing so you artificially make their software more expensive and give the smaller developers a government mandated advantage.  Only the natural market can set the bar for developers.  The government could, and perhaps should, set high standards for the software it purchases and perhaps by doing so, those high standards will trickle into the private sector.  But you can never get all the one-man contractors writing custom code for every business to comply with every best practice.

But then again, how can you put the burden on the developers when you have companies like Sony (just to name on of the millions) who store lists of internal passwords in unencrypted Excel spreadsheets in a "passwords" folder?  EVERY corporation in the world is littered with security idiots who think sending an unencrypted top secret file by SFTP is the same as a PGP encrypted top secret file sent by FTP.

I do have one major problem with one of your statements.  You said, "If you've been hacked, even if no privacy breach occurred, your customers have a right to know the details."  No, they don't.  As a customer, it would be NICE to know all the details if Target Stores found that a hacker had broken in and taken data from a planogram database, but I see absolutely no reason why I would have a "right" to know even the vague fact that it took place, much less any detail.  If in fact I DO have such a right, why would it be restricted to a cybercrime?  Shouldn't I also have the right to know the details of every crime committed against the business?  From an invasaion robbery to embezzlement to the slightest shoplifting?  I say no.
BrianY331
100%
0%
BrianY331,
User Rank: Strategist
1/29/2015 | 5:23:21 AM
Re: Problematic solutions at best.
I think that the assumption that the government knows anything more about solving these problems than the technical community is fundamentally flawed.  They know a lot less and move a lot more slowly than we do.  They also really only have one weapon which is to threaten people with fines or jail and that's not something they ought to be doing to honest hard-working engineers.  They should be focused on doing that kind of thing to bad guys, not the good guys.  Sure, it's true that we good guys are easier to find than the bad guys, but so what?  If they can't handle the big jobs they should get out of the way.

The rate of successful prosecutions for bad guys is dismally small and even more dismal overseas where a lot of criminal activities are going on.  Rather than trying to "help" us they should be doing their jobs as police agencies.

--Brian
Securecore
50%
50%
Securecore,
User Rank: Apprentice
1/27/2015 | 1:52:41 PM
Middle ware
Starting with NON open source middleware and using a government agency secrecy model, many of the security issues to date are within the capabilities of unique middleware programs being developed. Unlike the typical "cybersecurity" firms, these methods MUST stay proprietary within the domain their designed for.. as the net of everything has exposed us all and open source means opening the door. Locking down execution prior to compilation, yes within a C++ base and providing unique multithreaded, asynchronous event processing with no garbage collection which exclude memory trapping to ensure proper program execution are all coming. Unique memory management and string processing with exotic threading will hamper and deter many malware efforts and expose the rest.


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
How Enterprises are Attacking the Cybersecurity Problem
Concerns over supply chain vulnerabilities and attack visibility drove some significant changes in enterprise cybersecurity strategies over the past year. Dark Reading's 2021 Strategic Security Survey showed that many organizations are staying the course regarding the use of a mix of attack prevention and threat detection technologies and practices for dealing with cyber threats.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-41872
PUBLISHED: 2021-10-27
Skyworth Digital Technology Penguin Aurora Box 41502 has a denial of service vulnerability, which can be exploited by attackers to cause a denial of service.
CVE-2021-34580
PUBLISHED: 2021-10-27
In mymbCONNECT24, mbCONNECT24 <= 2.9.0 an unauthenticated user can enumerate valid backend users by checking what kind of response the server sends for crafted invalid login attempts.
CVE-2011-4126
PUBLISHED: 2021-10-27
Race condition issues were found in Calibre at devices/linux_mount_helper.c allowing unprivileged users the ability to mount any device to anywhere.
CVE-2011-4574
PUBLISHED: 2021-10-27
PolarSSL versions prior to v1.1 use the HAVEGE random number generation algorithm. At its heart, this uses timing information based on the processor's high resolution timer (the RDTSC instruction). This instruction can be virtualized, and some virtual machine hosts have chosen to disable this instru...
CVE-2020-7867
PUBLISHED: 2021-10-27
An improper input validation vulnerability in Helpu solution could allow a local attacker to arbitrary file creation and execution without click file transfer menu. It is possible to file in arbitrary directory for user because the viewer program receive the file from agent with privilege of adminis...