Comments
DevOps Tip: Don't Give Developers Keys To Security
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
Rich Krajewski
50%
50%
Rich Krajewski,
User Rank: Ninja
9/4/2014 | 4:48:18 PM
Good points but
Good points but it should result in an interesting group dynamic, where one group formalizes its distrust of another. I wonder how it will be carried out without tripling costs? I mean, it's the problem of costs that is allowing many of these weaknesses to exist, no?
steveshahcitrix
50%
50%
steveshahcitrix,
User Rank: Strategist
9/4/2014 | 4:26:56 PM
Re: Developers open ports when we need to???
I completely agree that developers should be trained to be security professionals as well. Their unit tests should include a significant amount of negative input and boundry testing at a minimum. QA processes should include static code analysis, fuzzing attacks, and full scans to validate at the system level.

Unfortunately, we aren't there yet and it doesn't take much reading on developer forums to see that we're far away from this ideal. In larger applications, end to end systems knowledge can be even harder to come by, let alone deep security know-how. So we continue to have network and application firewalls and specialized groups that focus on system / site-wide security. As long as we need those pieces, the need for enabling fast turnaround on making changes will remain.

Cheers,

-Steve

 
steveshahcitrix
50%
50%
steveshahcitrix,
User Rank: Strategist
9/4/2014 | 12:54:59 PM
Re: Very self-aware for a developer
Thanks. You should hear what I have to say about recovering sysadmins. :-)

-Steve (formerly trusted with UID 0 too... not so much anymore.)
Drew Conry-Murray
50%
50%
Drew Conry-Murray,
User Rank: Ninja
9/4/2014 | 12:31:19 PM
Re: Fast, Cheap, Out of Control?
Hi Steve,

Thanks for the candid reply. If this model becomes prominent, it seems like controllers are going to have to play a significant role for config and change management, whether as a de facto management point with a decent UI, or to feed into a larger management infrastructure. In any case, if better automation can help preserve domain expertise while also accelerating change, that seems like a win.
epeterson57002
50%
50%
epeterson57002,
User Rank: Apprentice
9/4/2014 | 9:32:45 AM
Developers open ports when we need to???
No "we" do not.  It's time to train and vet all server developers as security professionals.  There are many cases where a little less security awareness is needed (client dev, tool dev, library dev) but when a developer is implementing any kind of server project they should be tossed into the real insecure world from the very beginning.  Security cannot be layered on later by someone else.  Every developer on every server must start with patching, firewalls, securing the ports on whatever software they use, etc.  If they cannot do that, they need to be trained or reassigned.

One of the beauties of cheap VPS is that the VPS is in the real world from the moment it is deployed.  Every server developer should be able to deploy and secure one in five minutes, and spend a little extra time at each stage of development keeping it secure.  For example if they add user accounts, they have to immediately add access control else their VPS out on the open internet will get hacked.
steveshahcitrix
50%
50%
steveshahcitrix,
User Rank: Strategist
9/4/2014 | 1:58:02 AM
Re: Fast, Cheap, Out of Control?
Great question, Drew. To be perfectly transparent, this is an approach that is still new and is getting fleshed out by early adopters. The key in the approach is the adoption of network controllers for heavy automation. This lets the controller take care of keeping track of all those instances, which VLANs they run on, and which apps they are tied to. Thus, when an app is moved all the VMs that made up the app plus the supporting infrastructure (firewalls, load balancers, etc.) are taken along for the ride. Ditto with handling of instantiation and decommission.


Increasingly, some notion of a configuration template or recipie (think ACI or Puppet) is used to driving configuration across each instance. The vast majority of apps use a small handful of recipies while the remaining start to leverage one-off changes. This makes the changes easy to track from a central location and state management of the device easy to do. (Unsure of the device state? Let the system get it back to a known configuration for you.)

Net-net, the goal is to make changes quick. We can either trust developers (which I clearly don't agree with) or empower the security team to be able to drive change quickly. A highly automated template driven network is one approach to empowering the security team that I believe will be the method of choice for most organizations in the future.

-Steve
Gigi3
100%
0%
Gigi3,
User Rank: Ninja
9/4/2014 | 1:24:55 AM
Expert advices
"Developers open ports when we need to, without thinking about the implications for the broader business. We run roughshod over regulatory compliance. We don't give a moment's thought to the other developers we work with. We care only about making our own apps the best they can be."

Steve, most developers have similar working strategies. But when doing the major changes with security, it's always better to consult with domain experts.
mattwatson81
50%
50%
mattwatson81,
User Rank: Apprentice
9/3/2014 | 5:12:38 PM
Developer access
Developers have access problems because supporting production applications requires access to a lot of information and tools. Information and tools they don't typically have access to. 

Tools like Stackify can solve these problems by giving developers complete visibility to server health, application monitoring, errors, logs, and application performance from a single dashboard. With this type of visibility in one place, they no longer need backdoor production access just to view a log file.

 
Charlie Babcock
100%
0%
Charlie Babcock,
User Rank: Author
9/3/2014 | 4:53:18 PM
Virtualization has wrought far-reaching changes
In many ways, the firewall and network changes that Steve is talking about flow out of data center virtualization, which allows us to break big monolithic hardware and software components into smaller, logical chunks. This process is started, by no means finished. Thanks for approaching this topic wiith a sense of humor.
Drew Conry-Murray
100%
0%
Drew Conry-Murray,
User Rank: Ninja
9/3/2014 | 4:46:16 PM
Fast, Cheap, Out of Control?
This is a really interesting post, but I'd like to get your take on potential downsides of going with lots of small control points vs. a few large ones. I take your point that, for example, trying to accomodate the needs of a variety of applictaions that each has different requirements using just a few firewalls would make for a tortorous rule set. But it also seems like there could be just as many downsides with managing hundreds of firewall instances, each with their own special unicorn settings. All those instances need to be managed, kept track of, patched, decommissioned if their associated app goes away, etc.


Seems like there are definately trade-offs.
Page 1 / 2   >   >>


Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest, Dec. 9, 2014
Apps will make or break the tablet as a work device, but don't shortchange critical factors related to hardware, security, peripherals, and integration.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on InformationWeek.com for the week of December 14, 2014. Be here for the show and for the incredible Friday Afternoon Conversation that runs beside the program.
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.