BOSTON -- "Don't be 'that guy'," the saying goes, but when it comes to SecOps, it might not be good advice.
IT pros from six startup companies discussed the intersection between DevOps and security in a panel discussion here this week and agreed -- some having learned the hard way -- that it's a best practice to have security reviews done by one expert rather than by committee.
"[For] a lot of things we do, we review as a group and we look at tradeoffs," said Vikram Pillai, chief architect and director of engineering at CloudHealth Technologies, cloud service management platform maker in Boston. "Security is not one of them."
Datadog, which runs a software as a service (SaaS)-based monitoring platform in Boston, recently adopted a similar format.
"Before it was our CTO, one of the founders, and security was one of many things that he did," said Matt Williams, DevOps evangelist at Datadog. "We're constantly learning newer, better ways of doing things."
That one security expert is "one throat to choke" in the event of a problem, Pillai said, as well as a central coordinator with the deepest security knowledge on the team.
"Security is a place where, if one person comes in and makes a decision, they don't know what they don't know, and it's really hard to corral that back. Once the horse is out of the barn, you're dead," Pillai said. "Security is the one thing that we like to have one person on."
LogicMonitor Inc., a SaaS-based infrastructure monitoring company in Santa Barbara, Calif., is "trying to move from a more traditional, 'this is the security guy and we run audits every so often' to ... [a] security person that reviews new code changes and architecture," said Jeff Wozniak, technical operations engineer at the company.
SecOps vs. agility: finding the balance
SecOps has two, at times conflicting, mandates: to maintain security while letting a company move through software iterations quickly. Tradeoffs in security and agility are necessary in such environments, panelists agree. Panelists noted that customer-facing areas of an application are the highest priority for security, but internal utilities might be areas where software can be pushed out and security backfilled later on.
"Having such a small public footprint but such a crucial piece that lives in [a customer's] data center allows us to be flexible on where we want to focus our security energy versus our speed and agility energy," Wozniak said.
Public-facing software at Pretty Instant, an on-demand photography service in Mountain View, Calif., is just the tip of the DevOps iceberg. It takes priority over security requirements for internal applications. Employees and other internal users have been vetted and had their backgrounds checked by the company, said Doug Rogers, director of product and co-founder, "so the security requirements are not as high."
This prioritization is easier when customers are in high tech and fast-growing, like CloudHealth's early customers.
"They weren't asking us for a security position," Pillai said. "But now we have more customers in the enterprise space where we have to make firm declarations, so it's become more formal for us."
Problems between flexibility and security are handled by a small conference of about five stakeholders at CloudHealth, "and usually resolved pretty quickly," Pillai said.
When in doubt, the priority is security.
"We don't compromise on that," Pillai said.
Another security tip: Bake it into DevOps
Think your cloud is secure? Take the quiz
SecOps without saying "no" all the time