Some days I wish I was a screenwriter. There, nothing is out of bounds. Physics? Bah. Logic? Who needs that? How cool was it that the writers of Dallas (the show, not the city) decided to take a mulligan… on an entire season? Pretty cool, I’d say.
What if we could take a mulligan on some of those decisions we made years ago? You know, like parachute pants. Or signature-based antivirus. IDS. Token-based authentication. If you could pull a Dallas, what would you build? It’s a fascinating question. And one that I’d like to investigate – with your help, of course.
To be clear, this is a thought experiment. If you were just hired as the security architect for a company that had nothing, what would you implement? I’m not going to build a scenario with applications and number of locations and all that crap. Figure you work for a big company and somehow they’ve decided to start over again. You have applications and some even use the web. You have sensitive data, the kind that bad guys would love to get. You have lots of locations all over the world. And the powers that be just gave you the keys to the car. Now point it in the right direction.
So what would you do? And before you get bent around an axle, saying you need to implement a firewall and AV because the regulations say so, forget that. No compliance mandates here. You are focused on protecting the critical information in your organization. And money is no object.
What would be on your shopping list? What wouldn’t be? There are no wrong or right answers. I think it’ll be interesting to hear everyone’s opinions. I have posted some of my thoughts on Positivity, which make sense to me. That doesn’t mean they’re right.
Ready, set, discuss!
Photo credit: Green fields of wheat originally uploaded by Robert Crum
Reader interactions
9 Replies to “The Greenfield Project: How would you start over?”
Greenfield startup companies like Zynga are 100 percent in the cloud and leverage lots of cloud startup technology (including cloud security technologies). They have an extensive security strategy.
A company focused on greenfield app development should take an interest in pre-compile (source-code based) as well as runtime (i.e. wrapper based) DRM to protect their intellectual property in the cloud, especially PaaS. I think PaaS (like Force.com and Amazon Elastic Beanstalk) provide the most bang-for-buck to appdevs because of all of the bundled services.
A company that is not focused on app development should probably focus primarily on SaaS for their backoffice, and perhaps a mix of IaaS private and public cloud for the rest of their infrastructure. I hear VMware vConnector is a great way to balance the needs of cloud with in-house server virtualization — it allows an organization to migrate VMs from their private cloud to a public cloud. In this case, leveraging server virtualization security technologies would also be in order.
I would suggest checking out the work done by iSecPartners (especially Alex Stamos) on cloud security. Additionally, the work by Ed Haletky (he has a few books out on server virtualization security in addition to a company and website/wiki/blog) is top-notch. The Center for Internet Security provides some additional hardening guidelines that I think are extremely important for these environments.
Lastly, I don’t think that any company that does any serious money-making application development should be without a trusted adviser (or a few advisers) in Application Security Consulting. Similarly, any greenfield project should match extensive types of penetration-testing to their technology and business risks — testing not only the greenfield operation but also vetting potential SaaS/cloud and/or server virtualization vendors and providers.
I also think that every Greenfield security project leader should pick up a copy of Visibile Ops and Visible Ops Security so that ISO27k-like controls can be implemented in an efficient and sustainable way. However, this advice could equally apply to brownfield security project leaders.
Andre, I don’t think this post proposes that there is a magic this or a silver that, it merely asks what you would do if you were starting from scratch. This isn’t fantasy unless you think the notion of a start-up company is fantasy.
And, while each situation may be unique (though I challenge not to the extent to which you assert), there are common threads. Lots of snowflakes make snow, and everyone deals with large ammounts of snow in similar ways, to extend your analogy.
Can’t you just play along instead of pissing in the wheaties?
Move on to a brownfield project because the greenfield project is like the cake in the game Portal: it’s a lie.
Better yet, this whole exercise is an example of one of the primary problems in information security management: that people are not grounded in reality. There are no silver bullets. There is no magic list of information security controls. Checklists will not help you; nothing written or done before will help you.
Every situation is a unique snowflake. A disgusting, toxic-laden, barf-magnet snowflake. All solutions are custom, on-the-fly, completely ad-hoc and at best only last 5 minutes after they’ve been implemented (let alone documented).
The thing we would need for Greenfield deployments are people who understand this.
As an ongoing side project, I wonder how many of these greenfield items aren’t backed by hard values or metrics, but rather what experts feel will have an impact on the security posture… Sometimes, Get Things Done trumps haggling over numbers or ROI or risk or following some complex methodology to the letter? Good for a mature posture, but maybe more paralyzing for newer ventures?
Ouch, miss the captcha and my whole post gone. Doh! I’ll try to recreate without sounding too abrupt.
I think this is one of the more fun questions you can ask! I’ll assume this is a real world thing and there may be some animosity or internal inertia to changes, rather than a completely complacent ball of play-doh that can be molded endlessly (i.e. I wouldn’t recommend yanking out all local admin rights right away; this is painful and going to cause some tears…). I’ll also assume I can’t include on my wishlist a robust security staff from the start. Give me 50 people and I can spend some of them on menial crap that I normally wouldn’t bother with too early on (like watching WAF logs…).
– take inventory of the key people – talk to the people in the business from the desktop jockeys to the receptionists to the executives. Figure out who the players are and what they do. Figure out which ones are going to be a pain and which ones will be easy. Also figure out which ones you’ll be talking to when you ask the real down and dirty questions. This may lead into requesting some real security staff!
– take inventory of the business – Figure out what the business does and how the current technology allows those goals to be met. You don’t want to shoot yourself in the foot by opening up by stomping all over business process in the name of security. Also figure out which processes you can improve, not necessarily in the name of security, but you might be able to inject some security initiatives into other business projects as they come up!
– take inventory of the technology – This is where you start learning what software and hardware are present; what the IP address space is, the external footprint, and so on. Diagrams, IP/port scans, even vuln assessment tools help. Although, don’t get bogged down in the VA reports; just use them on the surface. This also includes internal software and web servers, etc.
– take inventory on the config and start improvements – This would be things like firewall and router configs, finding out where the external footprint is, where traffic and data flow, etc. Start working on tightening the configs, namely the firewall access rules, starting with ingress on the borders to egress from the internal.
– take inventory on the data – Know where the data stores are and what sort of weight/value they pose for the business. These locations will gain priority in all later projects.
– backups – Duh.
– patch management – It might be in vogue right now to question patching, but this is one of those things that everyone knows you should do, from technical to non-technical people. Sure, this might be painful for ops in certain environments, but even so, they know patches should be done.
– start cultivating a culture of segmentation – When working with the networking folks, always stress segmentation. You don’t need to dive head-first into such projects, but probably want to bring it up and implement better segmentation when current hardware gets replaced or upgraded.
– take inventory on the policies and start filling in any gaps. This will help keep anyone looking to help out in your initiatives a chance to know what to do. They don’t need to be perfect, but a skeletal framework is better than neglecting this.
– start a policy on terminated employee accounts disabling – This hopefully gets the ball rolling on working with HR and desktop folks who handle the accounts. If they buy into security procedures, everyone will. Besides, outdated accounts is a huge no-no and something that is so easily fixed.
– evaluate the risks posed to the company – Are you a defense contractor or just a B2B SMB? Different shops have different threats from web-based attacks to persistent attackers to opportunistic endpoint drive-bys. Figure out which ones to actually worry about (or namely, which ones you don’t need to worry much about).
– get a grasp on your physical security – This usually is a no-brainer to get the most basic of physical security for your locations, but take some effort to do more than a lock-and-key system and instead implement badge access wherever you can. Make sure data center locations are properly secure. Get an idea of any history of physical incidents; break-ins, missing systems, destruction procedures, etc.
– endpoint security rollout – This is traditionally the AV project. This is really a 2-fold project. First, to get some security on endpoint systems. Second, to get them managed centrally, to help cultivate the idea of central management of software overall. This can only help support costs, really.
I’ll stop for now. I’m sure I’m giving some items a grievous injustice by leaving them out of this 15-minute thought exercise!
I’m also purposely avoiding what I consider “tarpit” projects, i.e. projects that will lead to pain, tears, blood, and lots of time for possibly very little turnaround up front. Things like: removing local admin rights from people who aren’t used to it, IDS/IPS, log parsing and management, stringent network file/folder permissions, account/directory audits, vulnerability assessments, data classification… These are tasks that suck away time and energy and end up lacking just as often as they are actually valuable. Good ideas, all, but not necessarily something I’d want to jump into in Year 1. The goal in Year 1, for me, would be to get a good foundation in inventory as well as some easy wins to help pave the way for more imposing changes.
I think it might be useful to take every idea and rate tham on how soon they should be done, or maybe a series of ratings on value, ease-of-implementation, recurring time commits, business pain…thus hopefully getting a nice listing of the things to do early on and the things that are *way* further down the road (like a honeypot project).
I guess we differ in approach. I’m going to assume that, no matter what, I’m going to get owned. I’d rather have all the systems in place to know when it happens, who’s credentials were used, what data was accessed, etc.
I believe that as security controls become more complex and comprehensive, two things happen: a) the number of bugs increases dramatically and b) users start actively seeking to defeat them in order to perform their jobs with minimum hassle.
Application whitelisting and signed code immediately trigger my “users will bypass this at all cost” sensors. I also haven’t seen a proposal yet (admitted I haven’t looked very hard) for “secure hardware” that would allow open development. Maintaining secret keys and requiring NDAs for everything is slow, ponderous, and will be circumvented by both developers who want to get new stuff out fast, and users who want to use it.
Any way, I don’t mean to start a huge religious debate. I just figure I’ll plan for the flood instead of trying to think of every single way I might be able to prevent one. One way or another I will eventually need a boat. I might as well start with that.
Brian, your list is largely prophylactic. It’s a good list but not a greenfield. I’m not arguing these are not useful, but they are largely monitoring and response.
Positive comments: identity management is important and proactive. Can we add origin authentication as well (throughout the entire infrastructure, as we try to do with the telephony system)?
If you are going to start over, perhaps let’s try to address the systemic causes. Secure hardware/OS, whitelisted applications, strongly constrained user admin privileges, granular access controls on data, for example. Sandboxing. Signed, authenticated executables only. How about tagging personal data each time it’s accessed (by whom, when…)?
That’s probably more than a day’s work:-)
I know you are going to get tons of excellent technology suggestions. I want to make a social/cultural one.
Given your scenario, I’d want to instill a culture which forgave technical violations (like sharing your pw with your boss the day you were hospitalized due to a car crash, so she could finish off a presentation for a huge sales call) and had *real* accountability for “rules are for the little people”-type actions (such as a hotshot engineer back-dooring the network so she could get in even if “2FA didn’t work”).
I’d want the second instance to essentially result in a public execution. Too often, such events are either both winked at, or both treated as high crimes.
This is purely from the network/ops side, irrespective of development.
Roughly in order of implementation:
– Screening routers (NOT firewalls)
– Identity Management
– NTP
– System instrumentation/Log collection
– Log analysis/Event correlation
– Network segregation
– Data classification
– Data encryption
– Activity visualization/Anomaly detection
– Secure remote access/VPN
– Outbound proxies
– Patch management
That’s a good start. The basic idea is to first know everything that’s going on and be able to tie it to a specific identity. After that, start decreasing the attack surface.
You’re going to get popped no matter what. The key is to quickly understand that it a) has happened and b) how it happened. Incident response will be much easier with those pieces in place.
—
bk