Information Security Nightmares

It is safe to say that all IT and information security pros have had frightening IT challenges from time to time. Whether transitioning to the cloud or remedying false-positive alerts, IT engineers are often asked to think on their feet and adapt to change quickly.

Although the industry as a whole has come a long way, there are still some incredible stories lurking in the shadows of IT past.

Just in time for Halloween, industry experts have weighed in, sharing their IT nightmare stories (and lessons learned), as well as offering their analysis around DevSecOps (development of security operations).

For the record: The purpose and intent of DevSecOps is to build on the mindset that “everyone is responsible for security” with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required.

Further reading

Automating Core Security Functions

DevSecOps strives to automate core security tasks by embedding security controls and processes into the DevOps workflow. DevSecOps originally focused primarily on automating code security and testing, but now it also encompasses more operations-centric controls.

So enjoy this special Halloween eWEEK Data Points article.

Data Point No. 1: From George Gerchow, CSO, Sumo Logic:

What used to give you nightmares in the IT/information security world that doesn’t anymore? “Infrastructure issues. Throughout my career, whenever I would get a call for an outage, it was always due to some infrastructure or networking issue (misconfigurations of a router, etc.), which is really hard to troubleshoot. Now, as more businesses move to the public cloud, the issues are more focused on applications and data, things that are core to the business.”

So, is DevSecOps a “trick” or a “treat”? “It’s a treat. I am finding that whether it’s a buzzword or not, DevSecOps is leading to more automation in the security space, which I haven’t seen before. Working more tightly coupled with other departments within an organization is great. It may be a trendy term, but we’re reaping the benefits and I imagine other organizations are, too.”

Data Point No. 2: From Frederico Hakamine, CISSP, CCSP, Workforce Identity, APIs and Protocols, Okta:

What used to give you nightmares in the IT/information security world that doesn’t anymore? “Pop-ups, toolbars and browser plugins, and just thinking about it gives me chills. In my first job, I was in charge of managing the IT infrastructure in a small college, so you can imagine how hard it was. I’m so glad the browsers of today have vastly improved and this is a problem of the past.”

Is DevSecOps a “trick” or a “treat” or both? And why? “Definitely both. I really love how DevSecOps automates and delivers security throughout the dev lifecycle and how it removes friction between security and developers. My caveats are around the blind spots. Some people implement DevSecOps only on code, call it a day, and ignore other items such as the user login and the runtime environment. On top of that, some people also forget to keep their DevSecOps automation/scripts up-to-date. Just make sure you cover the blind spots and DevSecOps will be a treat.” 

Data Point No. 3: From Ben Newton, Director, Operations Marketing, Sumo Logic:

What used to give you nightmares in the IT/information security world that doesn’t anymore? “In a past life, I once had security guy take down all of our production servers because he was running a personal instance of VMWare connected directly to our servers in the data center. I haven’t seen a server in the flesh in 10+ years. So, no longer worried about that one.”

Is DevSecOps a “trick” or a “treat”? “One would hope for it to be a treat, but like many IT trends, it is just a trick if used as an excuse to re-label outdated security practices. Much like that costume with the fake muscles that is great for a 4-year-old on Halloween, but super creepy on an adult.”

Data Point No. 4: From Jeremy Proffitt, Staff Site Reliability Engineer, LendingTree:

What used to give you nightmares in the IT/information security world that doesn’t anymore? “Seeing those flickers that geeks recognize, whether slow load times, missing information or just old fashioned errors, without direction or focus–we found ourselves lost in a sea of intertwined systems. Those horrific moments of thinking something might be wrong have progressed to checking our alerts and being able to see in almost real time, the performance and errors in our systems.”

Is DevSecOps a “trick” or a “treat” or both? And why? “It’s important to remember the trick to DevOps, is to treat them only with facts, the hard evidence. A query link showing the issue makes understanding issues satisfyingly sweet.”

Data Point No. 5: From Ken Tidwell, VP of Security Engineering, Sumo Logic:

What used to give you nightmares in the IT/information security world that doesn’t anymore? “Scalability used to be a nightmare that haunted every information security process. The ascendance of cloud deployment with microservice architectures and on-demand lateral scaling has largely banished that nightmare.”

Is DevSecOps a “trick” or a “treat”? “DevSecOps is a treat. It provides the hard candy shell that protects all of your valuable intellectual property and processes. But remember that tricksters are out there. Mind your threat and intrusion indicators, and don’t just count on the invulnerability that a good DevSecOps process works toward.”












SEC Publishes New Guidance on Public Company Cybersecurity Disclosures : : Privacy & Information Security Law Blog

SEC Publishes New Guidance on Public Company Cybersecurity Disclosures

Posted on

On February 21, 2018, the U.S. Securities and Exchange Commission (“SEC”) published long-awaited cybersecurity interpretive guidance (the “Guidance”). The Guidance marks the first time that the five SEC commissioners, as opposed to agency staff, have provided guidance to U.S. public companies with regard to their cybersecurity disclosure and compliance obligations.

Because the Administrative Procedure Act still requires public notice and comment for any rulemaking, the SEC cannot legally use interpretive guidance to announce new law or policy; therefore, the Guidance is evolutionary, rather revolutionary. Still, it introduces several key topics for public companies, and builds on prior interpretive releases issued by agency staff in the past.

First, the Guidance reiterates public companies’ obligation to disclose material information to investors, particularly when that information concerns cybersecurity risks or incidents. Public companies may be required to make such disclosures in periodic reports in the context of (1) risk factors, (2) management’s discussion and analysis of financial results, (3) the description of the company’s business, (4) material legal proceedings, (5) financial statements, and (6) with respect to board risk oversight. Next, the Guidance addresses two topics not previously addressed by agency staff: the importance of cybersecurity policies and procedures in the context of disclosure controls, and the application of insider trading prohibitions in the cybersecurity context.

The Guidance emphasizes that public companies are not expected to publicly disclose specific, technical information about their cybersecurity systems, nor are they required to disclose potential system vulnerabilities in such detail as to empower threat actors to gain unauthorized access. Nevertheless, the SEC noted that while it may be necessary to cooperate with law enforcement and that ongoing investigation of a cybersecurity incident may affect the scope of disclosure regarding an incident, the mere existence of an ongoing internal or external investigation does not provide a basis for avoiding disclosures of a material cybersecurity incident. The guidance concludes with a reminder that public companies are prohibited in many circumstances from making selective disclosure about cybersecurity matters under SEC Regulation Fair Disclosure.

The Guidance is perhaps most notable for the issues it does not address. In a issued coincident with the release of the new guidance, Commissioner Kara Stein expressed disappointment that the Guidance did not go further to highlight four areas where she would have liked to see the SEC seek public comment:

  • rules that address improvements to the board’s risk management framework related to cyber risks and threats;
  • minimum standards to protect investors’ personally identifiable information, and whether such standards should be required for key market participants, such as broker-dealers, investment advisers and transfer agents;
  • rules that would require a public company to provide notice to investors (e.g., a Current Report on Form 8-K) in an appropriate time frame following a cyberattack, and to provide useful disclosure to investors without harming the company competitively; and
  • rules that are more programmatic and that would require a public company to develop and implement cybersecurity-related policies and procedures beyond basic disclosure.

Given the intense public and political interest in cybersecurity disclosure by public companies, we anticipate that this latest guidance will not be the SEC’s final word on this critical issue.