Stop Building Silos. Security Is Everyone’s Problem

Yes, it’s true that the speed of DevOps has made security more difficult. But that doesn’t mean accelerated release cycles and secure applications have to be mutually exclusive.

Recently, Prevoty CTO Kanal Anand raised an important question in a Dark Reading commentary pointing to several ways that security flaws are exacerbated by the speed of DevOps. Unfortunately, while it’s true that the Agile and DevOps movements have made security more difficult because of the volume of change occurring on a near-daily basis, it is totally not true that accelerated release cycles and secure applications are mutually exclusive.

The only way security flaws are identified in SQL scripts for production databases is through a manual review. For example, if user permissions are elevated via “grant sysdba to username” in a stored procedure, only a manual code review will catch this. Because this manual process is today trying (and failing) to keep pace with supercharged application development teams, bad code, unnecessary changes, or overly liberal access grants can slip through the cracks.

Given that security practitioners are currently on the outside of DevOps, this is understandable, though, it’s still not good. You try to check all that code with 100% accuracy. But if you’re trying to keep up with today’s release cycles, it probably won’t happen.

Vulnerabilities don’t slip through the cracks because of bad work on the database administrator’s (DBA) part, though. It’s not necessarily bad work by developers, either; it’s a symptom of old and new meeting head on at the last mile of an application release. On one side of the issue are the DBAs who, as I’ve said, just can’t really keep up with DevOps right now. On the other side are developers, whose need for speed was built on two words that can sometimes be dangerous: “fail fast.” That mentality can spawn lazy programming that looks for shortcuts, sometimes right around compliance with the data governance rules DBAs implement for very good reasons.

It would be easy to say that security shouldn’t bother developers toiling away to meet timetables. But we simply can’t have developers saying “security isn’t my job.” That would be in defiance of the changing reality of what DevOps teams do. DevOps is meant to get everyone involved in application development thinking system-wide. Rather than siloing DBAs and security practitioners even further, we can address security issues earlier in the pipeline and more effectively by inviting them – and their work – into the DevOps fold.

Extending DevOps tooling to automate database change management will greatly reduce the amount of manual work DBAs need to do, in turn reducing the likelihood that they’ll miss a change that creates risk to the business. If we automate the process of checking new code and database changes, we can be pretty much certain that they’re not going to miss an errant use of GRANTSYSDBA or a schema change that leaves a hole in the application.

[Read Kanal Anand commentary about Why Security and DevOps Can’t Be Friends.] 

Using automation in this way also lets DBAs enforce compliance earlier and more effectively. By disallowing “check-ins” for database changes that aren’t compliant, DBAs can stave off any changes that unduly exposes the business to risk, and can also train developers to write better code. Yes, extending DevOps to be “friends” with security doesn’t just give us better apps, it gives us better developers, too.

Finally, let’s go back to one of Anand’s key assertions: that we need to build security into apps at the application level rather than the perimeter. We can agree there for sure. But how can that be done in a lasting way without getting developers to think more deeply about security? And how can overworked DBAs create new defenses if they’re just struggling to keep themselves and their applications up and running?

I know all too well how resistant to change DBAs and security pros can be. But I also know that silos aren’t good for any business in any way. Instead of saying that DevOps simply moves too fast to be effectively secured, we should find a way to automate repeatable processes, get team members thinking about the security big-picture, and let our most versatile IT pros work on fighting tomorrow’s data attacks, not yesterday’s.

Related Content:

Gain insight into the latest threats and emerging best practices for managing them. Attend the Security Track at Interop Las Vegas, May 2-6. Register now!

As chief technical officer, Robert Reeves advocates for Datical’s customers and provides technical architecture leadership. Prior to co-founding Datical, Robert was a Director at the Austin Technology Incubator. At ATI, he provided real world entrepreneurial expertise to ATI … View Full Bio

More Insights

Stop Building Silos. Security Is Everyone’s Problem.

Yes, it’s true that the speed of DevOps has made security more difficult. But that doesn’t mean accelerated release cycles and secure applications have to be mutually exclusive.

Recently, Prevoty CTO Kanal Anand raised an important question in a Dark Reading commentary pointing to several ways that security flaws are exacerbated by the speed of DevOps. Unfortunately, while it’s true that the Agile and DevOps movements have made security more difficult because of the volume of change occurring on a near-daily basis, it is totally not true that accelerated release cycles and secure applications are mutually exclusive.

The only way security flaws are identified in SQL scripts for production databases is through a manual review. For example, if user permissions are elevated via “grant sysdba to username” in a stored procedure, only a manual code review will catch this. Because this manual process is today trying (and failing) to keep pace with supercharged application development teams, bad code, unnecessary changes, or overly liberal access grants can slip through the cracks.

Given that security practitioners are currently on the outside of DevOps, this is understandable, though, it’s still not good. You try to check all that code with 100% accuracy. But if you’re trying to keep up with today’s release cycles, it probably won’t happen.

Vulnerabilities don’t slip through the cracks because of bad work on the database administrator’s (DBA) part, though. It’s not necessarily bad work by developers, either; it’s a symptom of old and new meeting head on at the last mile of an application release. On one side of the issue are the DBAs who, as I’ve said, just can’t really keep up with DevOps right now. On the other side are developers, whose need for speed was built on two words that can sometimes be dangerous: “fail fast.” That mentality can spawn lazy programming that looks for shortcuts, sometimes right around compliance with the data governance rules DBAs implement for very good reasons.

It would be easy to say that security shouldn’t bother developers toiling away to meet timetables. But we simply can’t have developers saying “security isn’t my job.” That would be in defiance of the changing reality of what DevOps teams do. DevOps is meant to get everyone involved in application development thinking system-wide. Rather than siloing DBAs and security practitioners even further, we can address security issues earlier in the pipeline and more effectively by inviting them – and their work – into the DevOps fold.

Extending DevOps tooling to automate database change management will greatly reduce the amount of manual work DBAs need to do, in turn reducing the likelihood that they’ll miss a change that creates risk to the business. If we automate the process of checking new code and database changes, we can be pretty much certain that they’re not going to miss an errant use of GRANTSYSDBA or a schema change that leaves a hole in the application.

[Read Kanal Anand commentary about Why Security and DevOps Can’t Be Friends.] 

Using automation in this way also lets DBAs enforce compliance earlier and more effectively. By disallowing “check-ins” for database changes that aren’t compliant, DBAs can stave off any changes that unduly exposes the business to risk, and can also train developers to write better code. Yes, extending DevOps to be “friends” with security doesn’t just give us better apps, it gives us better developers, too.

Finally, let’s go back to one of Anand’s key assertions: that we need to build security into apps at the application level rather than the perimeter. We can agree there for sure. But how can that be done in a lasting way without getting developers to think more deeply about security? And how can overworked DBAs create new defenses if they’re just struggling to keep themselves and their applications up and running?

I know all too well how resistant to change DBAs and security pros can be. But I also know that silos aren’t good for any business in any way. Instead of saying that DevOps simply moves too fast to be effectively secured, we should find a way to automate repeatable processes, get team members thinking about the security big-picture, and let our most versatile IT pros work on fighting tomorrow’s data attacks, not yesterday’s.

Related Content:

Gain insight into the latest threats and emerging best practices for managing them. Attend the Security Track at Interop Las Vegas, May 2-6. Register now!

As chief technical officer, Robert Reeves advocates for Datical’s customers and provides technical architecture leadership. Prior to co-founding Datical, Robert was a Director at the Austin Technology Incubator. At ATI, he provided real world entrepreneurial expertise to ATI … View Full Bio

More Insights

Symantec CEO Brown’s Exit Highlights Company’s Continuing Struggles

For the third time since 2012, Symantec is looking for a new CEO to help turn around the business.

News this week that Symantec Corp. CEO Michael Brown will step down from office barely two years after being appointed to the role highlights the vendor’s continuing struggles turning its business around.

Brown’s pending departure—he will stay on until a successor is appointed—marks the third time in less than four years that Symantec has had a CEO leave amid disappointing sales.

In July 2012, Symantec fired chief executive Enrique Salem and replaced him with Board chairman Steve Bennett, in a bid to reverse the company’s declining fortunes at that time. Less than two years later, in March 2014, Symantec ousted Bennett in a surprise move and named Brown as interim CEO and president of the company. It formally confirmed him in that role in September 2014.

With Symantec announcing Brown’s planned departure this week, the mantle of interim CEO and president has now fallen on Ajei Gopal. A former CTO and executive vice president at Symantec, Gopal was most recently an operating partner at Silver Lake, a technology investment firm that recently made a $500 million strategic investment in Symantec.

In announcing the transition, Symantec offered no reason for Brown’s exit. Instead, board chairman Daniel Schulman lauded Brown’s execution on several of the company’s key priorities including the divestiture of Veritas, development of a new enterprise security product road map and improving Symantec’s overall cost structure.

“Given our solid financial foundation and clear path forward as the leader in cybersecurity, this is the right time to transition leadership for Symantec’s next chapter of growth,” Schulman said in a prepared statement.

But John Pescatore, director of emerging security trends at the SANS Institute, says Brown’s exit points to Symantec’s continuing struggles regaining its strategic focus after years of diversification.

Symantec started off and initially made a name for itself in the anti-virus business. Over the years the company branched off into areas that took it pretty fair afield of its core strengths, Pescatore says. As examples, he points to Symantec’s $13 billion acquisition of storage vendor Veritas in 2005, its $1.2 billion purchase of authentication vendor Verisign in 2010, and its acquisition of encryption technology provider PGP for around $300 million, also in 2010.

Analysts believe Symantec’s forays into multiple different areas, particularly the storage arena with Veritas, caused it to lose focus in the cybersecurity space. Recently the company has been trying to shed some of the weight it acquired over the years in a bid to streamline operations. After Brown took over as CEO, he initiated several changes aimed at getting the company refocused on its core security business. His biggest move in that direction by far was the divestiture of Veritas to the Carlyle Group last year for $8 billion.

In a recent interview with Dark Reading, Brown talked about his mission to get Symantec rededicated to enterprise cybersecurity. He pointed to Symantec’s new Advanced Threat Protection platform as an example of the technologies on which the company would focus moving forward.

Symantec would not be a one-stop shop for security technologies, Brown had noted. It would instead focus on areas of strength and opportunity like threat intelligence, security analytics, data leak protection, and cloud-based protection for advanced persistent threats.

But the plans may have been too little too late for Brown. Symantec’s revenues and earnings per share of $873 million and $0.22 respectively for the quarter ended March 31 were both below consensus estimates of $885 million and $0.24 to $0.27 per share. The company’s revenues for the past several quarters have been declining even as the cybersecurity industry itself has grown at a steady pace.

“I really think Symantec has had a lot of downward movement,” Pescatore says. In wanting Brown out, the board appears to have shown its impatience with the pace of change at the company, he says. “They have basically said ‘you haven’t shown us anything to show you are capable of turning this thing around’,” he says.

Pescatore says Symantec’s best bet going forward is next-generation endpoint protection technologies and mobile device management. “They need to pick a direction and get rid of everything that does not fit that direction,” he says. Over the long-term, Symantec could also benefit by positioning itself as an acquisition target, like McAfee was by Intel.

Related stories:

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

More Insights

Qatar National Bank Probes Possible Data Breach

Bank details exposed include those of ruling family and defense officials, reports say.

Qatar National Bank is probing reports of an online leak of confidential data of a large number of its customers, but has not confirmed it suffered a data breach, according to Reuters. Qatar-based Doha News reports say among the details leaked include names, passwords, and banking information of several Al-Jazeera journalists, “members of the ruling Al-Thani family” as well as government and defense officials.

Some 1.5GB of information was found online and Reuters reports seeing recent transactions of overseas remittances. Some of the account holders whose data is reportedly among the leaked files have verified the data was theirs.

The bank, one of the largest in the Middle East, declined to comment on the news but said that “there is no financial impact on our clients or the bank.”

For details on this story, click here.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

More Insights

FBI may soon be allowed to hack computers anywhere in the world

The Supreme Court has approved a rule change that will allow US judges to issue search warrants for accessing computers and devices in any jurisdiction.

fbi-has-been-developing-cyber-hacking-tools-for-over-a-decade-to-attack-criminals.jpg

(Image: Homeland Security)

That would greatly expand the FBI’s hacking capability, say civil liberties groups, who are opposing the planned changes.

Under existing rules, judges can only issue orders within their jurisdiction, often only a few miles across or a few local districts.

But the Justice Dept. argued the changes are necessary to keep up the pace against criminals, who often work across multiple jurisdictions — even countries.

“This amendment ensures that courts can be asked to review warrant applications in situations where is it currently unclear what judge has that authority. The amendment makes explicit that it does not change the traditional rules governing probable cause and notice,” said Peter Carr, a Justice Dept. spokesperson said in a statement.

The changes will allow the FBI to conduct network investigative techniques (NITs) — another term for hacking carried out by law enforcement — to remotely search computers located anywhere in the world.

But civil liberties group Access called on Congress to reject the rule change.

“While Congress is distracted rehashing long-settled debates about the use of encryption, the Department of Justice is quietly trying to grant themselves substantive authority to hack into computers and masking it as a bureaucratic update,” said Amie Stepanovich, US policy manager at digital rights group Access Now.

Google objected to the changes in 2015, shortly after the proposal was floated.

“The implications of this expansion of warrant power are significant, and are better addressed by Congress,” said Richard Salgado, legal director for Google’s law enforcement and information security unit.

Congress must approve the changes by December 1. If it’s ignored, the rule changes will automatically come into effect.