Enterprise Visibility

 

Enterprise Visibility

Would you drive to work every day with 3 flat tires, while blindfolded and juggling swords?  If so, please call me. If not, please read on.  

I’m not sure why we as defenders continue to allow ourselves to be subject to battles that we can not win, hell most times we can’t even see these battles coming.   No, I’m not talking about APT.  I’m talking about internal battles within our own enterprises and the obstacles we face in getting the necessary information to do our own jobs day in and day out.  Yet here we stand making the best our of the situation and trying each day to make progress an inch at a time until the next cataclysmic event occurs and we can shake a few dollars loose while we still have our 15 seconds of attention by the executive team.  There are a ton of reasons for this. Maybe we let a compliance initiative set our agenda for two years and now we can generate pretty reports so auditors can be appeased?  Maybe we can’t communicate a coherent strategy that allows for investment, or if we did maybe our supporters have gone onto other things?  Maybe our executive teams really just want to invest the bare minimum possible to avoid a fine?  

I could go on for days about how/why this happens, but I’d rather step out of that for a moment and refocus on what is critical.  My goal is to find a way to create a strategy with actual measurements for success that people can buy into that actually works.  Guess what - it’s not a product and no it’s not easy nor cheap.  It is however possible.  Our goal is to create a structure where information is available, people are enabled and identification is more accurate and response times are faster. 

The good news is that not ALL of your previous security investments are completely useless.  You can usually make the best of those tools (unless it’s AV, can’t help you there).  Sure the tools provided by companies like ArcSight, Splunk, NitroSecurity, AlienVault, NetWitness, Mandiant are all awesome at what they do, but without a truly complete set of information we’re still completely lost when it comes to dealing with today’s adversaries.

In order to be effective in your detection and response program you must be able to apply a microscope, magnifying glass, telescope and binoculars against the data within your enterprise at will.  In order to do that you have to have the right tools and the right data.  In my mind incomplete data is roughly equivalent to no data and in some cases may actually be even worse.  (More on that topic in the next post - Perspective).

There is a real need for a more holistic approach incorporating all data across the enterprise and using tools like Log Management, SIEM, Full Packet Capture and Forensic Tools.  The illustration above broadly describes what VisibleRisk means by Enterprise Visibility.  Context is our foundation and tools feed information from the perspective of the Host, Application, Network as well as the User and Forensic Data so that the Analyst has all of the information available at any given time and there is no time lost seeking it out.  The Analyst can be flexible and “Hunt” and create their own indicators.  The goals of this Enterprise Visibility program are summed up in three simple points.

1. Understanding Impact

2. Reducing time to Identification

3. Reducing time to Remediation.

Without all of the relevant information your time to identify the incident, understand the impact to your business and respond is unnecessarily increased.  Affirmative or Negative, each data point helps complete the picture so that your not filling in the “gaps” with guesses and responding inappropriately.  The faster the data is available the faster it can be analyzed and escalated and eventually the root cause can be remedied.  Every impediment to getting this information should be seen as a obstacle to the three stated goals and removed immediately.

Moving beyond what should already be accomplished the next steps once you have true Enterprise Visibility are around actually digging into the data beyond what is “alerted” to seek out new detection techniques and implement those indicators across the data set to look for more advanced attacks.  Your team should be spending the majority of their time doing this sort of analysis, not looking for data that already exists.  In reality it is very few and far between that we find teams outside of the DIB or Financial Sector that are doing this on a consistent basis.   That is simply unacceptable and a waste of resources across the board.  

We’ve outlined a few major categories of information that must be available to Analysts in order for them to protect the enterprise.  Without this information you are defenseless against the adversaries that have been pounding our networks/systems over the past decade. 

 

Logging

In the 2012 Verizon Data Breach Report it says that 84% of noted Incidents had evidence relating to that breach in the logs.  Just applying the simple 80/20 rule that so many people base critical purchasing decision on efforts around logging should be a a no-brainer.  Everyone must be logging correctly, right?  Oh wait the same report has a quote that indicates that less that 10% of those incidents were actually found by reviewing those logs.  The data existed but either no one was looking or they were looking at the wrong things.

Yes Log Management and/or SIEM (ArcSight, Splunk, Nitro, AlienVault, etc) tools can be very helpful when used appropriately.  But before you get started implementing those products here are some simple considerations.  

Everything in your enterprise should create a useful log.  If it doesn’t get rid of it.

There has to be a log standard across your enterprise and it needs to be enforced.  

If your team complains that turning on logging will affect performance, fire them, they should have designed you a better system. 

Yes I’m serious, you’ll fight all of those battles.  Prepare accordingly.   In the end you MUST: 

Get ALL of your logs into something that can be searched.  

Automate the trivial.  Alerting can and should be set up on common criteria, ensure the process is fully baked and the recipient understands their role in the process. 

I have a few years of blog posts on the subject of SIEM and Log Management.  If you want a more in-depth conversation I’d encourage you to take a peek when you have some free time.   

Network

Logs, Flows, Packets and Sessions. You need all four in order to be successful in understanding what is happening on your network and across your enterprise.  

Here is a silly example of the differences if you were to apply the same functionality to a phone conversation. 

Logs: “n” calls were made today.

Flows: “a” called “b” at (time) on this phone number.

Packets: “a” called “b” at (time) on phone and said (some keyword).  

“b” responded to “a” at (time) and said (some keyword).

Sessions: “a” and “b” talked and here is the context of there conversation, would you like to hear it?

Each one has significant value when you consider the type of analysis that can be accomplished.  From a Log/Flow perspective you can automate simple conditions that matter to your organization and conduct statistical analysis over the data.

From a Packet perspective if you know what you are looking to “trigger” on and have pre-identified it you can alert when it happens.

From a Session perspective you have the complete data to hunt within.  You can certainly gain more context about alerts generated from other identified means but more importantly you have the ability to create new indicators.  This is the most important part of moving forward and maturing as a team.  If you are not creating new indicators daily (or refining existing ones) you are fighting a losing battle.  The ability to adapt and overcome obstacles (or adversaries) is greatly enabled by having the right set of data in front of you.

Operating System

10 years ago dealing with Operating Systems logs was a nightmare.   Mainly because logging was an afterthought to a design or an incremental project for an IT team.  Today it’s pretty simple and highly effective.  The goal should be every system on your network, yes even the endpoints.  Your teams can create GPO or apply standards however they like as long as it is consistent and communicated.  

Yes, you might have to install an agent or use a service account and a WMI call to gather the logs from Windows systems.  

No relying on endpoint protection (AV/HIPS) and their respective logs is not enough coverage to matter.  

Yes parsing errors will occur and you may not understand all of the logs in the system initially, but this really is a case where have data is crucial to success.  The richness of these logs and the data that can be mined from them both in real time and forensically is pretty well documented.  The data within the log and the meta data about the log (size for example) will be a huge help in finding anomalies in your enterprise. 

Application / Database

Major or Minor EVERY application should provide a log file.  Whether it is SAP, Oracle, IIS or the collaboration tool being tested by your engineers it needs to provide a log and that log must be available.  Application logs are a nightmare to comprehend because they require deep knowledge of all of the hundreds of applications in use across your enterprise and the specifics of how well that vendor created their oh-so-helpful log messages (“Opps something broke”).  

Ideally these apps will log a standard time, process id, user id, code pointers and output something meaningful but any evidence will help your investigation.  The creation of a log entry in an of itself may be helpful.   I find starting with the application owners and learning how they troubleshoot is a great way to start to generate content for monitoring.  It’s amazing what you can accomplish over a lunch conversation. 

Personality

User, Admin, Service - All account types across Domain(s), Systems and Applications.  There by gold in them thar hills.  User information is or course valuable as a piece of context to help validate identity and from there authorization.  There is also usage of that information that helps support “hunting” activities and not simply context for other alerts.  The ability to mine that data and look for anomalies or to validate process makes the effort worthwhile.  

You probably have a great HR process to disable accounts from the domain once people leave and I’m sure that same system also helps grant privileges and ensure proper privileges as people move to new groups within the organization.  I’m sure no one has legacy access.  Accounts, Service Accounts and Domain Admin accounts never get compromised and all is happy.  Yep and Pompeii experienced a slight fog.   Let’s be honest your accounts are all over the map a jumbled mess in apps here and there. 

• Every Domain Account (No one uses workgroups anymore, right?…. right?) should be logged and integrated with your tools.  I should easily be able to look up Domain ID to Workstation ID and Username.  It shouldn’t take 2 days of DHCP log research (assuming the person with access to the log server isn’t on vacation).  
• Not only should this information be available but standard auditing techniques should be enforced ALL the time not just as the result of a pre-audit assessment once a year.  
• The idea of looking at users in relation to other similar users within their peer group for statistical anomalies or overt differences should be commonplace.  But in reality how may of you do it?  
• How your users/admins access data (from which systems and times) is an easy way to help identify “normal” and therefore suspicious.  
• Audits of users in critical systems/applications with admin type roles should be happening daily.  
• How many SAP* users do you have?  why?  
• How many users exist on your domain?  The number will surely outnumber the number of employees you have but by what multiple?

Identity Analysis Tools like Securonix go along way to helping you figure this type of information out.  USE THEM!

Forensics

Network

Logs, Flows, Packets and Sessions Data - ALL of it.  With regards to forensics we’ll focus on Session Data or Packet Capture and the associated analytics.  In short this is simply not optional anymore.  You SIEM is NOT enough. The question is more about % coverage and identifying not only perimeter coverage but also “core” coverage for lateral movement within your enterprise.  Certainly you’ll never hit 100% of all networks, but that shouldn’t mean you stay at “0”.  Perimeter data is an easy and highly effective start.  

Internal traffic is a much harder problem for a few reasons:

1. We’re not used to it,

2. Tools are not tuned for that kind of data and

3. There is a ton of it.  

That said the ability to detect stuff moving within your network is highly valuable.

Of course top tier commercial tools exist to help with this (NetWitness NextGen for example) but you can accomplish this with open source tools as well.  In either case you will need expertise in dealing with this the tools are extrodinary but only if used properly.  There are not Alerting engines these are hunting engines when used properly.  Outsourcing this is difficult most MSSP’s are not equipped to help you here because it breaks their service model (alerts).  The true value in these tools isn’t in the forensic research post-incident.  The real value is in the “hunting” that is enabled in the small subset of these tools that allow analytics to be the focus.  With the right team you can create new indicators on a daily basis instead of waiting on someone else to provide that detect weeks later.

End Point

The ability to quickly obtain images from drives across all assets in your enterprise is pretty common and most people have figured it out as a response for e-discovery (man that’s backwards).  The following statement applies to all forensics information (network, endpoint, memory) having the  the forensics data available at any given moment can mean the difference between knowing what data left your enterprise (or was altered) and who was responsible and being completely in the dark.  Yes this includes all endpoints including mobile devices. 

Memory

Memory acquisition and forensics analysis is very similar to forensics related to end points but distinct enough in practice to warrant being called out independently.  The tools are similar (Encase, FTK, F-Response, etc) but the rapid nature of acquisition and analysis can mean the difference between knowing within minutes/hours versus waiting for an acquisition to complete over a period of days.  From an open source analysis perspective check out Volatility. 

I don’t want to neglect hugely important things like Malware Reversing.  Your team has to have this capability in order to understand both the scope and the impact of the compromises your enterprise experiences.  

Context

Context for Security Analysis is generally an afterthought unless it happens to be baked into tools here and there.  It is incredibly important to look at both having this data available and also finding ways to keep it current on a consistent basis. 

Behaviors:

What is normal on your network?  So many people have ideas about what is normal but almost none of them talk or collaborate until it’s too late.  System / Application owners have their thoughts, business owners have their assumptions and of course there is what is documented and in the end we’re left with what is actually happening.   There are partial truths throughout, but shouldn’t all of these perspectives be available?

Criticality:

Data Classification would be ideal start to help understand criticality of information, but in most organisations this is still years away from being a full blown reality.  Simple things like understanding the operational impact (to the business and to IT) of each system, data store and user should be possibly by reviewing your DR/BC processes.  Assuming that data is complete/updated/available of course.   I mean you did pass your last audit right?  

Asset Information:

You have easy access to information about every asset on your network right?  I’m sure there is no such thing as a “unmanaged asset” on your network.  How many times during an incident response do you find out about systems that everyone assumed were patched or accessible to your tools (forensics or logs for example) but when you attempt to grab information you learn you don’t have access?  Having a quality asset management program helps avoid this situation.  Do it.  Understand the business, application owner information and quickly be able to involve them as necessary help reduce time to understanding impact and get to remediation. 

Business Function: 

What purpose does this system/data/user serve within our enterprise?  It’s a web server is insufficient.  It’s a web server that provides (pick your content here) to our key business partners supporting our new initiative is better.  Understand how important that system is to your business will help you better your understanding of Risk not just technical impact. 

Vulnerabilty:

This has to be one of the easiest sets of data to obtain and integrate and yet so many organizations are still way behind the curve on this one.  You should be running scans constantly with profiles that evolve as quickly as your organization does.  The “asset” information context alone makes these tools worth their investment, but understanding the vulnerabilities that exist on the system makes the analyst life even easier - it also allows for very quick identification for remediation activities across the enterprise.  Ad-Hoc, Planned, authenticated, internal/external scans should be running constantly and the results should be evaluated, prioritized and remediation acted upon and tracked.  Why you would run a tool and ignore it’s output by just assuming you have mitigating controls is beyond me, but it happens all the time.  This one falls into the “yes it’s that easy” category.

Correlation:

Context from existing correlation rules or logic within SIEM tools or other tools in your enterprise are valuable resources for investigating incidents.  Many times you’ll find logic errors or lack of data necessary to trigger those rules, especially as early in your enterprise visibility program.  Other times you may quickly see expansion in scope or be able to create automation around detection to help more quickly find new or expanding events.  

Intelligence:

Open Source, Commercial, Collaborative, Industry, Competitive, Threat, Tribal there are a ton of sources for information that can be used to help refine your analysis.  In some cases it can help refine alerting, at other times it is simply a corroborating set of data to help give you additional confidence.  In almost all cases it is underutilized, overly relied on or completely misunderstood.  Yes you should invest in obtaining, creating and refining intelligence for your organization.  This might include the creation of a threat intelligence team and certainly includes creating a way to collaborate with your peers across the industry.  You are all victims of serious crimes, learn how to defend yourselves and each other.  

Summary:

Complete Enterprise Visibility (Data, Context) creates a a higher probability of identifying an incident, it reduces the time to identify the incident and it helps reduce the time towards remediation thereby reducing the impact to your organization of any incident/compromise event.  Enterprise Visibility when combined within the right processes and in the hands of capable team members creates Flexibility to deal with the advanced adversaries we face today, in short it helps you create a Defensible Enterprise.  Fighting blind or otherwise standing in the way of our defensive capabilities only serves to help our adversaries.  Our goal is to help organize how defenders looks at their security program and provide some guidance so that we can level the playing field a bit. 

The Defensible Enterprise

This overview post kicks off a multi-part series on Defensible Enterprise, Enterprise Visibility and Perspective. 

Maybe someday I’ll create a series of posts outlining the absolute failures of our tools, processes or teams, but as it stands I’m pretty sure any data breach report or yearly incident summary points out those failures rather effectively.  I’ll just summarize my points and say the following: The playing field is constantly morphing both because of the constant people, data, technology changes within our organizations and because our adversaries have the ability to change the rules to benefit them at any point.  Yet here we are defending our outdated, stagnant and porous enterprises against adversaries who don’t really even have to think all that hard about how to score.  You can look at it as a lost cause or you can put your big boy pants on and say “Bring it on A-Holes”.

One of our goals is to help organizations achieve a state of “defensibility”.  Initially when we talk about defensibility we’re really focused on understanding what it is we are protecting, what tools are available to us and how we can maximize our effectiveness in detecting and/or minimizing the impact of a compromise.  In short we want define the weapons we have at our disposal to allow us to “adapt and overcome”.  

The approach I’ve been focused on incorporates a few key areas that help enable a more defensible enterprise.

• Enterprise Visibility
• Context
• Speed
• Flexibility
• Expertise.
• Process

 

Enterprise Visibility:  “All the Data All the Time”

The idea that I try to get across is that certain tools like Log Management/SIEM are good but not nearly enough when you are building a true Enterprise Visibility capability within your organization.  I’ll dig into this much deeper in the next post, but in the end you need the ability to “see” everything, Logs (Operating Systems, Application, Network, Security), Forensic Data (Host, Network and Memory) and User information as well as all the “context” residing throughout your enterprise. 

Context: “Oh wait – THAT user/system/data was compromised?!?!?!?!”

Vulnerability Scan information and Asset Information are fairly common (and very important) examples but not nearly the end of the resources required to be successful.  Having ALL of the information available, immediately, is required.  Obviously this information may be key to understanding technical aspects and increasing efficiency but in many cases it is the key to unlocking the actual impact to the organization.  Often times the context is the sole piece of information necessary to understand the Risk the organization actually faces.  

Speed: “Time to Identification/Remediation”

There are three measurements that matter to me.  1.  What is the impact, 3. How fast can we detect and 3. How fast can we respond.  Everything else is in the way.   Your team needs tools, processes, expertise and authority to analyze and act.  Without context and data available you’re spending precious time gathering it so it can be analyzed.  Without expertise your wasting time asking others and without the authority to get all of that ahead of time you’re just on the JV team.   If the time it takes your adversary to get into your network and extract data is measured in seconds to minutes and your change control window is measured in weeks – who wins?

Flexibility: “Adapt and Overcome”

Change happens…. Eventually.  This view must be annihilated if you want to succeed.  You may need to dig into data you are uncomfortable with or enter conversations above your pay grade to find what you need.  Obstacles are simple delay mechanisms, crush them and if you cannot break them then go around them.   Yep I’m telling you it is ok to break the “rules”.  If you need to move or adjust your tools to gain better perspective of an active incident – DO IT.  Certainly if you can bake that into the process ahead of time it makes it easier, but even if you can’t – make the change, beg for forgiveness and then update the policy afterward.  Along the same lines if your security team is solely alert driven you are doomed to fail.  Find new ways to conduct analysis with the data you have available or can get.  (more on this topic soon).  You should be updating your tools, processes, expertise on an hourly, or at least daily basis.

Expertise: “Singer, Songwriter, Choreographer, Lawyer, Doctor, Firefighter, Astronaut, Meter Maid, Special Agent, Fashion Designer and Clown”

We must have expertise in so many areas, Security Analysis, Incident Response, Forensics, Malware Reversing, Threat Intelligence, Security Architecture and in soft skills like Advising, Coaching and Mentoring.  Plus you have to do it on a training budget of $1500/yr.   Great people want to work on great teams.  Invest in your team (time, energy and dollars).   

Process: “Standardized yet Flexible”

Our goal is to create a fast, flexible set of processes and information that experts can manage and bring down the time to identify and remediate incidents.  We should be able to execute a “game plan” without having to write the play book each time.  Everyone involved should know the plan, authority and responsibilities established and trained against.  The “norm” in response should not be based on Herculean efforts.   That said your plan needs to allow for an audible.  A good plan will have everyone’s buy-in and trust. 

Summary:

I believe these stated goals are realistically attainable and at the same time I fully understand that all of these require significant investment across the board.  The reality of our situation is pretty simple, our adversaries have changed the game.  If you or your executive team don’t like it - “tough sh!t”.  Seriously.  Unless you don’t mind all of your information exposed, indexed and simply common knowledge by the rest of the world you had better figure out how to start to move past your checklists and trust in outdated methodologies and move towards allowing your people to do their jobs to the best of their ability.  The high-level steps identified in this post go a long way towards positioning your team in that direction.  It’s a compass not a GPS.

Thanks for reading!  Next week I’ll post my “Enterprise Visibility” chart and definitions.   A new look on something I’ve been trying to articulate for years.  In that post I’ll explore some of the goals necessary to reach a point of Enterprise Visibility in your organization.   The “Perspective” post is a simple view into understanding what it is exactly you are able to see and what gaps you still may have. A very simple but illuminating task.  Until next time.   - Rocky

BSides Austin 2012

We’re really looking forward to BSides Austin this year.  We’ve decided to become a sponsor for the conference and you can even see us present!  For the presentation we’ll be talking about how to passively profile web browser traffic to determine what is going across the network and using it to find interesting traffic and unknown threats.  If you’re going to be at BSides please be sure to say “Hi”.  There are some great talks and training lined up, so if you’re one of the lucky few to not be wait-listed you’ll be in for a treat!

More information on the conference can be found here: http://www.securitybsides.com/w/page/50371774/BSidesAustin2012

MIRCON 2011

I’m honored that my friends (special nod to Richard Bejtlich) over at Mandiant have invited me to participate in their second annual Incident Response Conference (MIRcon).  

I’ll be participating in a couple of different panel discussions on the “Management Track” at MIRcon.  These include topics like career growth for Incident Responders and discussions around insourcing/outsourcing for CIRT.  

I’d highly encourage anyone in the area (Alexandria, VA) on Oct 11, 12th to attend these sessions.  Mandiant does a great job putting the right audience(s) together with engaging topics.  Scheduled keynote sessions from Richard A. Clarke and Michael Chertoff should not be missed!  Of course I’ll be sure to share my thoughts post-MIRcon in the visiblerisk blog and I’ll tweet (@rockyd, @visiblerisk) and probably try out Google+ to relay thoughts and lessons learned during the conference.

Plan "A" is never enough.

Recent events in my area have made me update my personal response plan(s) to emergency situations for my family.  Since I was updating them I thought I’d share some tips I’ve learned over the years.  Of course you can get a more full list of ideas from http://www.ready.gov/, FEMA or your local emergency operations centers but hopefully this will help a few of you to prepare more robustly.

Lessons Learned:  Emergency Notifications may or may not occur proactively.  Once power goes out it’s even less likely notifications will occur.  Primary mechanism is emergency alert via radio/tv which is great if you have a battery powered radio on or available all the time.  (Lesson Learned: Alternative Energy and/or Batteries are your friend).

• I absolutely recommend the following Reading/Preparation Guide: FedHealth’s  ”It’s A Disaster and What are you going to do about it”  These folks have walked through situations like Flood, Fire, Hurricane, Earthquake, Landslide, etc and put together some great ideas on specific preparation and mitigation strategies for each situation.  My specific advice - Put the book in your main bathroom to guarantee everyone reads it on a periodic basis (seriously).

• Local News Radio (AM or FM):  This is one I overlooked being a addict of Pandora/iTunes/Spotify but thus far Local Radio has been very solid for updates especially on traffic (and when you’re driving watching TV/surfing internet can be difficult).  I didn’t even know what local stations existed here before tonight.

• Local Red Cross Locations/Website/Phone Numbers.  I didn’t have these programmed in our phones before today.  Normally evacuations centers are local schools, most can accommodate pets (but not all).  Know where they are, how to get there and make sure your kids can do the same.

• City/County Emergency Operations Center EOC website/phone - again should have had these pre-programmed in our phones.   Less important because you can dial 911, but good source of information if your trying to learn more about the situation and don’t want to overwhelm emergency staff. 

• Twitter/Facebook/Google+ As of tonight - in addition to #hastags - I’ve started to create geographically localized Circles, Lists.  Easier to communicate with those affected, plan for alternatives, etc.  Potentially A very powerful tool.

• Cell Phone:  Since 911 and DC Sniper events I’ve made sure my kids have them in their backpacks.   Now there’s obviously a downside to that, but the kids know that their phone’s primary function is as an emergency device, not entertainment.   Location Tracking via cell phone.   Tonight a friend’s daughter was stranded away from her family due to a wildfire.  Her family’s neighborhood was also put under evacuation orders and very quickly thereafter her house was without power.  This made positive contact difficult. Having location tracking on the cell phone helped but it was not perfect.  Emergency crews are way too overwhelmed to search for a single separated person, but you can use your contacts (phone, email, FB, and trusted twitter/G+ groups to help you search).  A closely related lesson learned here - every kid is getting an extended battery/case ASAP.  I will not have cell phone dying on them (or me) if I can avoid it.

General Tips:

• Keep fuel level in cars above 1/2 tank.  Always.  Learned this lesson from spending many years in FL and through way too many hurricane seasons.  In an emergency power goes out, fuel pumps stop working and incredible lines form for any remaining operable ones.  Storms can be unpredictable and you may need to move out of harms way more than once do you have enough gas?

• Keep cash, power outages mean increased difficulty in processing credit/debit transactions.  Usually I’d suggest an emergency reserve of 1 week to support your family (Lodging, Food, etc).  In some cases you’ll have time to grab clothes for a week in others (fire) you won’t.  Plan for worst case.

• Important papers most can be replaced rather easily (Birth Certificates can be re-ordered, etc) if you’re going to prioritize passports are easily transported and relatively small.  I keep mine in a zip lock bag in a safe for grab and go purposes.

• Contact Information - make an password encrypted doc available with contact information, personal information, etc available on a key ring USB device.  It’s possible your cell phone will get lost/wet/broken in the shuffle but generally people remember their keys for whatever reason.  Make sure you have plan a-z  thought through - who could you stay with for a week if you were ejected from your home tonight?  What if you could only drive North? or West?.  Plan ahead.  

• Know your neighborhood - how wide are the streets? Are they wide enough to allow you to pass if there is an stalled car or accident blocking part of the road?  If not how many alternate exits exist to bring you to safety?  How many alternatives exist that put you in harms way (traffic jam or in the path of a wildfire/tornado)?  This will obviously vary by scenario so know them all.

• Every time in response to real emergency events or after near misses - review what worked, what could have been better and refine the plan.

• Last Lesson Learned for tonight - In your emergency kit add cell phone charger (It helps if your family standardizes on a single device or at least devices that can use the same type of charger).