Friday, June 20, 2008

Day 1: Starting at the beginning

You’re hired on at a new company placed in charge of securing their online business (websites). You know next to nothing about the technical details of the infrastructure other than they have no existing web/software security program and a significant portion of the organizations revenues are generated through their websites.

What is the very first thing do on day 1?

The idea here is to collect wisdom from the crowd (avoiding multiple choice), see if we can find reoccurring themes, order them accordingly, and then move onto the next step. And please don’t say pour a cup of coffee. :)

28 comments:

Billy (BK) Rios said...

Take some time to understand the core competencies, critical business processes, and critical data that your organization owns. Use these core business needs to prioritize your security efforts.

Jeremiah Grossman said...

Thanks Billy, I guess its only fair that I answer as well...

Figure out what you now own. Identify any/all internal/external websites, what they do, who's responsible for them (if anyone), what data they contain, and their relative value to the business.

Victor M.J. said...

Open a Diet Coke! For me it would be developing a network infrastructure. I'm into visio maps to organize my thinking. From the Internet to routers, firewalls, switches, I'd want to be sure the basics were secure first. Patch's second, and securing the Web Traffic with an applications firewall last.

Pau/ Hummer said...

I think the first thing you ought to do is use the website and chat with the developers. Experience will show you the hints of where your obvious starting points will be.

Matt Franz said...

People should be #1 -- the "rest is commentary" as they say. What are the formal roles? What are the teams? Who really gets things done or makes decisions? Is there a program manager somewhere that has the keys to the kingdom and knows everybody. Is there a motivated QA guy that "wants to learn security." Who is that one architect that knows everything (pipe dream) that can whiteboard the app infrastructure that will make threat modeling possible, etc.

Mark said...

1) Pull all of your DNS entries and check them for 80, 443 and all other common web ports. Then dust off nmap and scan the entire production infrastructure for the same, then the development infrastructure (workstations optional), Invintory in your favorite bit bucket storage utility.

2) For each entry, identify webserver, app server, static/dynamic app, app language, db server, poc info.

3) Contact said poc, verify step 2 info, gather exact versions of all application software, libraries, servers and db's

4) Identify all the seriously old architecture out there, patch it

5) While ops guys are doign 4, sit with leadership/development manager and identify business critical applications from the list generated in 2 and updated in 3

6) Build assessment team, get them to work on existing code

7) Build process team, get them to integrate security into the SDLC, develop/purchase developer training , develop metrics to see if SDLC and training is working, adjust accordingly

8) Pray your still employed

Anonymous said...

I guess I would hack their coffee machine, just to prove a point! ;)

/rvdh

0x000000.com

rwnin said...

seems like we already know what the core business is, ie: in the question it is stated that web apps are critical foo and a significant revenue source.

given that, my first question is do we have logs? inbound web app traffic logs, outbound fw logs for the hosting servers, host OS logs, ids logs, full packet capture logs at entry/egress points, etc.

if i can't see what is happening, then i'm managing risk via perception rather than reality...?

Mike Rothman said...

The first thing is to figure out priorities. That means you need to meet with as many high level folks as possible in the first few days. It's critical to understand what is the most important data (and therefore applications) and then who is going to be fired if that data is breached.

You can't do everything, so if you are starting something new - at least protect the right stuff.

I hear there is a Pragmatic guide that goes into this kind of stuff. :-)

Mike.
http://www.pragmaticcso.com
http://blog.securityincite.com

Jon Daley said...

If you are replacing someone, or maybe even if not, change the passwords, probably most passwords haven't been changed in years, and so various contractors, old IT guys, former girlfriends, etc. have access to change your data, but have been nice enough not to up to this point.

Jordan said...

Lot of other excellent ideas in the comments already.

I do want to second rwnin's comment though. Logs from day one. You can do all the other items on day two, but you can't go back and mine logs that don't exist.

As an added bonus, when you identify the logs in the first place you're going to have to get in touch with all the right people anyway. Network admins, server admins, db admins, etc.

YADotSoB (yet another disciple of the school of Bejtlich)

Arshan Dabirsiaghi said...

1. Establish where all the hot girls are (usually marketing and accounting)
2. Make up reasons for visiting aforementioned departments
3. Grow a mysterious, swashbuckling image of yourself with suggestive remarks about a past life of crime, travel, royalty, adventure and car chases
4. Hide all your D&D character sheets (even your level 19 fighter who has negative 5 AC... WITHOUT ARMOR Zomg!!!1)
5. Get hacked
6. Install ScanAlert or get McFeters certified
7. Sleep easy

Did I forget anything?

Sheran said...

1. Get internal technical team to brief me on the infrastructure
2. If there are glaring security holes after the briefing, study possibilities for technology to provide quick wins and immediate security to the infrastructure. Then follow internal processes to have them purchased.
3. Shop around for a third party to conduct a security assessment. I'll be initially looking for:
- [ ] An External Security Assessment (Infrastructure and Application)
- [ ] Source Code Review
Again, follow internal procurement procedures to have the third party security team hired on an urgent basis.
4. Look at internal technical staff potential (if a dedicated security team does not exist) in order to have some of the stronger team members form a pseudo security team. Meanwhile, identify weaknesses in areas of security and plan to hire people to fill these gaps
5. Depending on 4. above, build an Incident Response Team and/or procedures on how to address Business Continuity and what to do in case I am hacked. I would make this very comprehensive and spend the most time on this.

This is probably as much time as I would have on Day 1 realistically speaking and through experience.

Jeremiah Grossman said...

From the comments received I'm going to distill each arbitrary "day" down into groupings of ordered tasks (with examples if possible) - then tie them all together in a flow chart of sorts. Should make for an interesting and useful web security program build out by day 5.

Andre Gironda said...

Create a document with:
1. SWOT
2. Identification of issues
3. Prioritization of issues

bachrach44 said...

A lot of people have said essentially to take an inventory, and I guess I would have to agree. You have to know what you need to secure before you can secure it. Try to talk to the right people to identify all of the web apps and servers in your environment. Then figure out what they do, and how important they are to the business.

Andrew van der Stock said...

Buy in for security is not a given. Steaming in and making changes is a career limiting move.

I'd spend some time to meet and greet - find out who the chickens and the pigs are, and build bridges with the business.

I'd make sure that folks know that I'm open and approachable no matter how far out their ideas are. It's better to know than to be a mushroom.

Everyone is given a certain grace period to settle in, understand what the priorities are and so on, but you cannot undo or re-do your first impressions.

Mechanical crap like getting badges, machines, office space, etc can wait.

As a senior person, I like to think about what I'd set out to do in my first 90 - 365 days well before 8 am on the first day. I have a message (let's do some secure business!), and a basic plan for sure, but beyond that, it's going to take a while to learn what's really wrong and how best to fix it. Some folks might try to get to you early to get their version of events. They may be telling the truth, often they're not. Wait a while to figure that out.

Lastly, if you make a lot of announcements early, you will miss out on one of the most powerful CYA mechanisms - blaming the person before you for unpopular changes, write downs, changing processes or killing them off, changing vendors, or killing wasteful projects. That period can be milked for some time if you play your cards right. ;-)

Andrew

Don C. Weber said...

I think that everybody should take another look at Mike Rothman's and Andrew Van Der Stock's comments as they are critical.

Jumping into an organization with a Gung-ho attitude and vast knowledge of analysis tools is great but you have to remember that people have been there for a while and conducting business. They understand what is going on and why the environment is in its current state.

First thing: sit down with the "People" of the organization. Start with your executive introductions and determine the core objectives of the IT and development departments. What services are they providing and which ones are critical to keep everything running (and everybody getting paid). This goes to Mike's priorities.

After the executives move to your peers in the IT and development departments. During your conversations with them be sure to use terms like "I'm here to help." "Our level of service to the customer is priority." "We know I will be recommending changes, but I am open to suggestion and clarification." "How do I get integrated into your processes and procedures?" "Open communications is essential. Please come to me with any questions, concerns, or recommendations." This is the positive, team player attitude that Andrew brought up.

First impressions are key. You have to present yourself as a team player willing to integrate and work towards making the business more successful through security.

Also, from a personal stand point, you have to realize that you will be working on a moving target as everything is already in place. Changing the direction of a moving target is much harder. Patience and persistence will be essential. Come to the job knowing that change will take some time to accomplish and hard work will probably be required.

Good luck to all in this position.

Go forth and do good things,
Don C. Weber

Matt Presson said...

I would definitely say do the meet and greet thing for the first day. I completely agree with Andrew that coming in like Gang Busters and starting to change everything just screams "I am an elitist. I know more than you, and always will." Not a very good way to start out with people whose development process you are going to drastically change.

Second, find out what you own - apps, sites, servers, etc both publicly facing and internally facing.

Second day (being preemptive here)

Document what type of data each above system handles and start to find out how critical that data is to the company.

Start setting up some type of data classification system with minimum requirements for protecting each classification level.

Chris Eng said...

Going to comment before reading all the others, to remain neutral.

1) Resist the urge to dive in and start "fixing" things immediately. Making sudden and/or unpopular moves too quickly can burn political capital that you don't even have yet.

2) Understand the organizational structure, how different business units interact with one another, who is responsible for what. Are there any would-be security champions/detractors that will be influential in gaining buy-in?

3) Schedule high-level meetings with execs to get a handle on business priorities.

4) Start to enumerate the application inventory using the data from previous steps, and rank them by business criticality. Understand the longevity and security maturity of each.

Only at this point is it practical to start prioritizing actions and figuring out how best to accomplish them within budget constraints. Oh... you DO have a budget, right?

Mike Montecillo said...

I'm inclined to agree with Matt Farnz here on your first day people should be #1. Although I would actually say that beyond just learning peoples roles and capabilities it would also be important to learn the political environment as well.

When you are being brought on to enhance security the chances are that there is something broken or rather not security focused in the most basic processes. This means that some type of change needs to occur. Identifying where that change needs to be made will be easy. Figuring out a way to create that change will be much more difficult.

The real trick to ensuring security is to get other non-security focused teams to create the security posture.
It's not something technical that forces a change, it's political. If you learn to leverage the politics to create the proper processes to fix the technical issues you tend to be better off. Put simply, learn how to create a security culture.

On a side note...if you should completely disagree with me and agree more with Mark's post. Before you dive into scanning everything consider finding an old HP printer and using the -sI switch in nMap to idle scan off of the printer. You'll probably have a job for a day or two longer haha :-D

Jeremiah Grossman said...

I'm noticing a lot of comments about meeting with people in the various organizational groups, especially upper management, to develop "business objectives" or "priorities". Could you please list some as examples?

The list doesn't need to be exhaustive, but enough of the more common objectives/priorities so they can be placed in a mind map.

Andy, ITGuy said...

First you have to understand the web application and exactly what it does. What systems does it connect to on the back end and what inter-dependencies do they have with other systems. Once you know that you can then meet with the business units to understand how they use the data and look at what protections are currently in place. You also need to have an understanding of where do they want to go with their web presence. What plans do they have to expand or add functionality.

Anonymous said...

Find out what you are and aren't allowed to do. The best laid plans of mice and men are usually bound up in red tape and fiefdoms. Sorry, too much time working in gov't.

infosecramblings said...

I'll toss my agreement with several others who have stated that your first priority is building relationships with the executives whose people are going to have to make all the changes you are likely to be pushing for in the near future.

But, even before doing that, I think it is vital that as the new security dude or dudette, we have to ensure we have the backing and support of the highest levels of management. If the CEO, CIO, etc. level folks are not behind you, you are going to have a hard time getting others to buy in. Hopefully this was taken care of during the hiring process.

Kevin

The Grumpy Hacker said...

A bit off topic Jeremiah but have you heard about this?

Jeremiah Grossman said...

about what?

Allen Baranov, CISSP said...

There are some rather lofty ideas of what to do on the first day but my first choice would be - check that the basics are in place.

Are the PCs using passwords, is there anti-virus in place, is there a process to keep it up-to-date. Is there a patching program. Check your own PC and those of the people around you for what software is installed, how up-to-date it is. Is there a firewall? Is it effective?

Once that is done.. then move on to the other things such as interacting with business, risk assessments et al.