Perhaps the most important thing someone in operations can do is to educate developer to the security controls available in your environment.
- Teach the idea of least privilege.
- Explain how auditing works.
- If giving developers root access and then backing into least privilege is how you run your shop, explain what you're looking for (ports, file access, commands, etc.)
- If sudo is the preferred method of privilege escalation, give them some insight into how you manage sudo.
- If centralized authentication is encouraged, make sure they have easy access to create new accounts (easy being "within minutes").
- If you have centralized authorization, or use groups and group membership for authorization, explain it to them and make it easy to get.
The list goes on, but as I write it, two themes come to mind.
* Make it easy to get service credentials, access to group membership during development.
I think the worse case scenario is the developer builds their own authentication and authorization system because they couldn't get what they need. From a developers perspective, how is it they can provision 20 machines in 5 minutes, but it takes 5 days to get a login name.
* Give developers full access with audit in development.
This should test your audit capabilities. Let them loose and then tighten down least privilege. If a user keeps 'sudo su -' to get something done, go find out why 'sudo cmd' isn't working.
Once the app is built, deploying to production should put those policies into effect. If you require staging to test first, so be it. If you can test in production rolling the change out in a controlled way, great. Since security configuration is almost parallel to system configuration and both represent change management, make sure they are treated equally.
On Mar 14, 2012, at 12:14 PM, Chad Woolley wrote:
> On Wed, Mar 14, 2012 at 11:48 AM, Matt Ryanczak <ryan...@gmail.com> wrote: >> I'm curious how others view the development, implementation and maintenance >> of system and application security in a devops world. > > Everybody and every project has different security needs. It's all > about risk vs. return, and people love to go overboard on security. > > Here's one "pretty good" approach: > > * Lock down every port you aren't using at the box and firewall > * Make all your boxes only accessible only via SSH through a bastion host > * Have reasonable policies on SSH keys and password security > (reasonable again depends on your app domain and individual situation) > * Have easy access to all logs via a tool like Splunk (to have all > info easily accessible if you do suspect a security breach). > > Even some of those are overkill for some situations. > > Then, on your actual boxes, do The Simplest Thing That Could Possibly > Work, which means not going overboard on security. > > In other words, do everything you can to keep people out of your > boxes. If they actually get into your boxes, you're already pwnd, so > it's pointless to make your day-to-day life harder in order to deal > with that scenario. > > For me (my case is an interpreted app environment - Ruby/Rails), this > means running everything as a non-root user (except stuff that can't > by design, like nginx/apache), and setting up NOPASSWD sudoers for > that user. > > For external monitoring or anything else which might represent a risky > but necessary attack vector, you can set up independent > security-restricted users that only have access to the files/resources > they need. E.g. your Nagios/scoutapp.com jobs might only have > read-only access to basic OS or database metrics, but have no access > to real data or any write access to anything. > > That's my $.02. I am not a security professional, and I'm sure many > people disagree with me :) > > -- Chad