Once again, it was an honor and pleasure to speak to the Kingsport Chamber of Commerce this morning. I have created this snippet of the event to share. Thanks.
Step #1 – Admit That You Have a Problem
Many IT professionals live in a world of denial. Assumptions are made about the security of systems and risks are often ignored. These stances are not taken out of ignorance or irresponsibility, but are instead often-pragmatic decisions based on the number of resources available and the number of hours in a day. IT managers are frequently forced to hope that the diligence that went into the deployment and configuration of network equipment and servers 3 years ago will continue to protect that equipment today. Unfortunately, that is often far from reality.
The first and most important step for all IT professionals is to recognize and admit that vulnerabilities are real and that they are a problem to be tackled consistently and systematically. Attack vectors change, software evolves, and firmware gets revised. Very little if any part of information technology is static. Recognizing this fact is key. Once you admit that problems exist, solutions become a possibility.
Step #2 – Define and Understand Your Boundaries
Once you recognize that there is a vulnerability problem to be tackled, the next step is to start to define the battle and the related battlefield. Certain questions must be answered initially. What tools do I currently have at my disposal (vulnerability scanners, logs, discovery tools, monitoring tools, asset management information, etc.)? How many locations and subnets do I need to evaluate? What impact will this work have on my network? What are my potential maintenance windows?
The answers to these questions will help to define your next steps including what needs to be purchased, who needs to be called, and how quickly you can dig in and start working the problem. Rome was not built in a day, so remember that patience is key. The development of a strong plan is the foundation for success.
Step #3 – Know Thyself
Knowing thyself means a lot of things to a lot of people but in terms of vulnerability management it means understanding how many devices you have on your network, where those devices are located and what potential function they have. This process usually begins with a discovery scan across all subnets. In a perfect world (and I know all IT shops are generally utopic J), this type of scan validates all of the existing asset management inventories and there are no surprises. In reality, a good discovery scan can identify lost or forgotten components, expose unauthorized devices, backfill or create asset inventory lists, and provide a strong starting point for vulnerability remediation.
Step #4 – Address the Obvious Problems First
Most IT professionals do not need to perform extensive testing or run numerous scans to identify their “problem children” on the network. Every organization has certain servers and network devices that are adverse to patching or downtime or both. Build a plan, schedule the necessary downtime and patch these devices. There is no need to wait for a vulnerability assessment to know that these machines will need to be addressed. Plus, the cleaner the initial vulnerability assessment, the faster remediation can begin.
Also, remember Step #3. Review your discovery scan and target any anomalies. All unknown or unexpected devices should be investigated and all unnecessary and unused machines should be decommissioned.
Step #5 – Assess Your Situation
At the heart of every good vulnerability management strategy is a thorough vulnerability assessment utilizing an established and exhaustive scanning tool. Several important decisions go into a strong initial vulnerability assessment. Select a reputable scanning tool with a mature vulnerability signature database. This will limit false positives and ensure valuable initial scan results. Using the results of your initial discovery scan, target all assets on your network. Do not make assumptions as to which devices should or should not be scanned. Scan them all. Target a maintenance window that will allow for as much potential down time as possible. This will allow for a more thorough and intrusive scan of all nodes without impacting business functionality. Finally, be patient. A thorough scan takes time and monitoring. Be aware of your maintenance window and be prepared to pause your scan to ensure production is not affected.
Step #6 – Remediation is Fundamental
This particular step is quite possibly the most important and the most easily forgotten step in good vulnerability management. A strong vulnerability assessment is only as good as the time and effort put into the remediation of the assessment’s findings. Far too often organizations diligently scan their networks only to set aside the resulting report and never fix any problems. Scanning becomes a compliance checkbox effort while the remediation work falls to the bottom the tasks list.
Review your vulnerability scan results. Build a remediation plan starting with your most vulnerable and critical systems first. Then work the plan. Realize and accept the fact that all findings cannot be remediated quickly and some findings may find their way onto the next scheduled scan. That’s ok. Be methodical and eventually those results reports will be smaller and smaller and your network will be more and more secure.
Step #7 – Reassess Your Situation Every Few Month
Simply completing a vulnerability scan and successfully remediating all of the related findings is not the same thing as reaching the end of the vulnerability management rainbow. You are not done. The clock starts all over again. Like its close cousin patch management, vulnerability management is a continuous process and, as such, requires a consistent methodology. Develop a set of quarterly procedures including discovery scans, vulnerability assessments and remediation tasks. Such a strategy will shorten vulnerability windows and give you a bit more peace of mind from quarterly interval to interval.
Step #8 – Develop Better Habits
As has been stated throughout this list, a lack of patches and up-to-date firmware is often a root cause of vulnerabilities on systems. IT professionals the world-over have the best of intentions when it comes to the development and implementation of a patch management strategy. Unfortunately, project schedules and real world challenges interfere with those strategies, leading to interruptions if not the complete abandonment of system patching. No good comes from this.
IT professionals should make patch management and, as an extension, vulnerability management methodical and habitual. Time should be built into work schedules and project plans to ensure these critical tasks are complete. Resources should be dedicated to remediation. Both planning and execution are necessary to ensure all systems are as hardened and as defensible as possible in the event of a cyber-threat.
Step #9 – Increase Your Frequency
Vulnerability management and the plans and processes associated with it should evolve over time. As remediation strategies become more effective, each follow-up vulnerability scan report should be smaller and more manageable. Once those reports become more manageable, the time between scans can shrink. The more frequently an IT shop scans for and remediates vulnerabilities, the less time that shop and its associated organization spends vulnerable to potential threats. Less vulnerability is always a good thing.
A good strategy for scanning intervals is to attempt to shrink from quarterly to monthly, and then from monthly to weekly. Most professionals would agree that an attack window of seven days is much more palatable than an attack window of 90 days.
Step #10 – Make It Automatic
The inevitable challenge that comes with more frequent vulnerability assessments is having the time and resources to perform the scans. Fortunately, most of the leading scanning tools and vulnerability management solutions have automation mechanisms to help solve this problem. A good tool/solution should allow an administrator to schedule scans as needed and to route the results of those scans to an email box or file share automatically. A good tool/solution should also generate alerts based on critical findings or system conflicts associated with the scanning process. This level of automation should free up administrators and allow for more frequent and burden free scans, which in turn provides valuable insight and smaller vulnerability windows.
Step #11 – Learn to Follow the Trends
Aside from the immediate goal of identifying and eliminating network and device vulnerabilities, a strong vulnerability management methodology also provides invaluable insight into the function and effectiveness of an organization’s IT security practice. By tracking the vulnerabilities and threats identified in the scanning process in relation to the remediation process designed to eliminate those threats, an IT security practice can demonstrate its effectiveness and the organization’s overall security posture over time.
Many of the more robust vulnerability management solutions on the market today can track remediation successes over time and provide reports and graphs demonstrating the effectiveness of the vulnerability management methodology. This is a valuable tool for most IT security practices because it validates all of the efforts exerted to keep an organization safe and it also provides a financial justification for resources acquired and monies spent.
Step #12 – Make Continuous Progress
This final step makes the assumption that scanning and remediation are moving along smoothly and vulnerability windows have been shrunk to as small as possible. Many vulnerability management solutions and threat intelligence platforms now support Layer 7 continuous monitoring of networks for potential vulnerabilities and threats. This is accomplished through passive packet inspection and traffic pattern recognition. Such a solution is the logical next step in vulnerability management; knowing the problem as it occurs.
That being said, perhaps assumptions should not be made. Maybe an IT shop’s vulnerability management methodology does not need to be perfect. Continuous monitoring has value regardless of the state of your vulnerability management strategy. Knowing you have a problem is truly half the battle. But remember that knowing you have a problem is not the same thing as solving it. That takes a plan and that takes proper execution.
Good Luck! Go fight the good fight against bugs and vulnerabilities!
This is just one link to one of dozens of articles concerning the Sony breach and the subsequent pulling of “The Interview” from movie theaters around the country. I like many of you am both angered and frustrated at this entire situation, from Sony’s response to the conjecture of retaliatory attacks by the US government against North Korea.
First and foremost, this entire situation is an example of cyber-bullying targeted at the US Constitution and its freedom of expression as well as the very nature of capitalism in a free market society. Every American should be outraged that the acts of one nation state could influence what appears at an American theater. It really is that simple. Corporate America is bowing to the whim of a violent dictator. We are setting a very dangerous precedent by allowing this to happen.
Secondly, Sony is clearly not guiltless in this situation either. Like most instances of bullying, Sony was not prepared for conflict. They found themselves cornered on the playground with their IT pants pulled down around their ankles due to a complete and utter disregard for proper cyber defenses. Other corporations desperately need to take notice and prepare themselves. There are plenty of bullies on the playground of our world’s economic stage and the environment is ripe for a wave of similar extortion attempts and cyber attacks.
Finally, retaliation in the forms being bantered around via public media outlets is not the answer. There are no real value-added cyber targets in North Korea and the attack itself was clearly outsourced to players located in other locations throughout the world. Retaliation and retribution need to come in the form of real world controls. This is not a tit for tat situation. At the end of the day, the American infrastructure is under attack, either physically or economically, and that kind of threat should be handled in a serious manner and at the highest levels of government. As citizens, we have a right and responsibility to demand this of our elected officials. Do not be lulled into thinking this is just about a silly movie and the bruised egos of the Hollywood elite.
In light of the tragic shooting in Portland, Oregon today, I thought it appropriate to post some relevant content concerning active shoot scenarios. I recently prepared much of this content as a mechanism to help others plan and prepare for such an incident. Incident response planning is a tremendously important process for all organizations. Planning is a proven first step to mitigating the impact of these tragic events. Most of this content was collected from three sources:
Department of Homeland Security – Active Shooter Preparedness: http://www.dhs.gov/active-shooter-preparedness
Federal Bureau of Investigation – Law Enforcement Bulletin – Addressing the Problem of the Active Shooter By Katherine W. Schweit, J.D.: http://www.fbi.gov/stats-services/publications/law-enforcement-bulletin/2013/May/active-shooter
New York City Police Department – Active Shooter Recommendations and Analysis for Risk Mitigation: http://www.nypdshield.org/public/SiteFiles/documents/Activeshooter.pdf
The Department of Homeland Security (DHS) defines an active shooter as “an individual actively engaged in killing or attempting to kill people in a confined and populated area.” In its definition, DHS further notes that, “in most cases, active shooters use firearm(s) and there is no pattern or method to their selection of victims.” This is the scenario each business, organization and individual should consider and prepare for accordingly.
The following are valuable statistics to consider when developing an active shooter response plan. These statistics are provided by the Federal Bureau of Investigation and the New York City Police Department:
- The average active-shooter incident lasts 12 minutes. 37% last less than 5 minutes.
- In 98% of incidents, the offender is a single shooter.
- 97% of all offenders are male.
- In 40% of incidents, the offender commits suicide.
- The median age of an offender is 35 years old. However, this median conceals a more complicated distribution. The distribution of ages is bimodal, with an initial peak for shootings at schools by 15-19 year olds, and a second peak in non-school facilities by 35-44 year olds.
- The average number of deaths in an incident is 3.1. The average number of wounded individuals is 3.9.
- Active-shooter incidents often occur in small- and medium-sized communities where police departments are limited by budget constraints and small workforces.
- 43% of the time, the attack is over before the police arrive at the scene.
- When law enforcement arrives while the shooting is underway, the shooter often stops as soon as he/she hears or sees law enforcement.
- 24% of all incidents occur in an open commercial space. 11% occur in an office building.
The FBI has provided a list of relevant points when considering active shooters. These points are very important when developing training material for employees and, specifically, human resources personnel. These key considerations of an active shooter include:
1) There is no one demographic profile of an active shooter.
2) Many active shooters display observable pre-attack behaviors, which, if recognized, can lead to the disruption of the planned attack.
3) The pathway to targeted violence typically involves an unresolved real or perceived grievance and an ideation of a violent resolution that eventually moves from thought to research, planning, and preparation.
4) A thorough threat assessment typically necessitates a holistic review of an individual of concern, including historical, clinical, and contextual factors.
5) Human bystanders generally represent the greatest opportunity for the detection and recognition of an active shooter prior to his or her attack.
6) Concerning active shooters, a person who makes a threat is rarely the same as the person who poses a threat.
7) Successful threat management of a person of concern often involves long-term caretaking and coordination between law enforcement, mental health care, and social services.
8) Exclusionary interventions (e.g., expulsion, termination) do not necessarily represent the end of threat-management efforts.
9) While not every active shooter can be identified and thwarted prior to attacking, many potential active shooters who appear to be on a trajectory toward violence can be stopped.
10) The FBI’s Behavioral Analysis Unit is available to assist state and local agencies in the assessment and management of threatening persons and communications.
The following content has been sourced from the Department of Homeland Security and the New York City Police Department and is considered a best practices approach to preparing for an active shooter incident.
- Conduct a realistic security assessment to determine the facility’s vulnerability to an active shooter attack.
- Identify multiple evacuation routes and practice evacuations under varying conditions; post evacuation routes in conspicuous locations throughout the facility; ensure that evacuation routes account for individuals with special needs and disabilities.
- Designate shelter locations with thick walls, solid doors with locks, minimal interior windows, first-aid emergency kits, communication devices, and duress alarms.
- Designate a point-of-contact with knowledge of the facility’s security procedures and floor plan to liaise with police and other emergency agencies in the event of an attack.
- Incorporate an active shooter drill into the organization’s emergency preparedness procedures.
- Limit access to blueprints, floor plans, and other documents containing sensitive security information, but make sure these documents are available to law enforcement responding to an incident.
- Establish a central command station for building security.
- Put in place credential-based access control systems that provide accurate attendance reporting, limit unauthorized entry, and do not impede emergency egress.
- Put in place closed-circuit television systems that provide domain awareness of the entire facility and its perimeter; ensure that video feeds are viewable from a central command station.
- Put in place communications infrastructure that allows for facility-wide, real-time messaging.
- Put in place elevator systems that may be controlled or locked down from a central command station.
Train Employees and Building Occupants:
- Evacuate if at all possible. Building occupants should evacuate the facility if safe to do so; evacuees should leave behind their belongings, visualize their entire escape route before beginning to move, and avoid using elevators or escalators.
- If evacuation is not possible, then hide. Building occupants should hide in a secure area (preferably a designated shelter location), lock the door, blockade the door with heavy furniture, cover all windows, turn off all lights, silence any electronic devices, lie on the floor, and remain silent.
- Take action as a last resort. If neither evacuating the facility nor seeking shelter is possible, building occupants should attempt to disrupt and/or incapacitate the active shooter by throwing objects, using aggressive force, and yelling.
- Employees and building occupants should be trained to call 911 as soon as it is safe to do so.
- Make sure employees and building occupants are trained on how to respond to law enforcement when they arrive on scene: follow all official instructions, remain calm, keep hands empty and visible at all times, and avoid making sudden or alarming movements.
The content of this document should provide the foundation for decision making when developing policies, plans and procedures to deal with an active shooter scenario. When questions arise during the development of these documents, do not hesitate to reach out to local, state, and federal law enforcement for guidance and clarification.
A good friend and colleague Michael Burgess, CISSP, sent me the following message this morning:
“I’ve been doing some research and thought you may benefit from (if you haven’t already ran across it). Some have begin adding an addition to a well known acronym and a core principle in information security. I think it is picking up steam and with good reason.
Accountability as in the process of tracing, or being able to trace activities to a responsible source….I think it is a good addition given experiences and how often accountability is needed, or would have been helpful.”
I think Mr. Burgess and the growing movement to expand the traditional triad are spot on. Accountability is an important principle in IT Security and is closely tied to the principles of data integrity, confidentiality and availability. It speaks to the responsibilities of data stewards and data owners and the need for security analysts to capture activities and report on anomalous behavior.
Kudos to Michael for bringing this idea forward and continuing the conversation to our profession stronger.
Many of you have seen press coverage or the many online updates involving the POODLE vulnerability. After the fallout surrounding the HeartBleed vulnerability, websites and web application vendors are not taking any chances and have saturated mailboxes and web banners with alerts for their potential users. I sincerely appreciate this diligence, but it can lead to some confusion over the risks facing customers and application owners.
Let me start by saying there is a significant difference between HeartBleed and POODLE. HeartBleed is based on a flaw found in a version of OpenSSL that was extremely popular for web servers hosting some of the most frequented sites on the web including national banks and the world’s largest online retailer. HeartBleed affected millions of online customers and resulted in the loss of tens of thousands of hours in IT resources to validate and upgrade web servers around the world.
Pardon the pun, but POODLE is a completely different animal. POODLE is based on a flaw within SSLv3. SSLv3 is a block cipher dating back more than 18 years and this particular vulnerability manipulates the padding added to an encrypted block when it is too short for the algorithm. Based on its age, it is rarely used on webpages today. It has been largely replaced by one of several versions of TLS (Transport Layer Security). Consider these facts:
- SSLv3 was originally released in 1996. TLS 1.0 (Transport Layer Security) was released in 1999 as an upgrade to SSLv3. The latest released version of TLS is 1.2 which became available in August 2008.
- SSLv3 only accounts for approximately 0.3% of all HTTPS Internet connections.
- Of the Alexa Top Million Domains of the Internet, only 0.42% have some reliance on SSLv3, and that is typically tied to a subdomain.
Clearly, the threat footprint for POODLE pails in comparison to HeartBleed. That does not mean we should not take steps to alleviate the threat. Most of the websites that still leverage SSLv3 are moving away from it and toward TLS. Internet Explorer 6.o is the only major browser still in production that does not support TLS 1.0 or higher, making it the last hurdle for those still forced to utilize it. In fact, most web browsers are moving to disable support for SSLv3.
- Firefox Version 34, slated for release on November 25, will disable SSLv3 by default.
- Microsoft has announced its plan to disable support for SSLv3 in Internet Explorer and all of its online services over the next few months.
- Microsoft has also released a FixIt tool that allows users to disable SSLv3 support in any of the currently supported version of Internet Explorer.
- Google Chrome and Firefox both currently support SCSV (Signaling Cipher Suite Value) which is a TLS Fallback mechanism to prevent protocol downgrade attacks such as POODLE.
As an IT Security professional, I am always thrilled to see the world at large take threats and vulnerabilities seriously. But I do become concerned when the media overreacts to a threat or begins to paint all vulnerabilities and incidents with the same broad brush. By doing so, we either become hyper-sensitive to every threat, large or small, or we become completely desensitized to all threats, leaving us more vulnerable to criminal activity. At the end of the day, I hope we can reach a balance where each incident is dealt with appropriately and given the weight it deserves.
With the official launch of Apple Pay today, I wanted to take a moment and talk about the potential pro’s and con’s of using an eWallet in general (Google Wallet or Square for example) and Apple Pay specifically.
Let’s start with the fundamentals. Google Wallet, Square, Apple Pay and most other eWallet options rely on NFC to transmit and receive data. NFC stands for near field communications and is a proximity-based network technology built into many popular smartphones including the Samsung Galaxy s5 and the iPhone 6. NFC operates in a range of approximately 3 – 10 cm and over a frequency of 13.56MHz. The basic procedure for a physical purchase transaction using NFC via a smartphone goes something like this:
– Customer selects a payment option on his/her phone
– Customer holds the phone an inch or two from the retailer’s payment terminal
– A few beeps occur and like magic, the transaction goes through.
To the consumer, this type of payment option seems like a great deal. No cards were swiped. The phone remained in their possession. They didn’t even have to reach for their wallet. Unfortunately, from a fraud perspective, a few things are left to be desired.
Let’s start by discussing the pitfalls of traditional NFC eWallets like Google Wallet. Even though a physical card is not swiped during the transaction, Google Wallet and most others in this traditional category still transmit cardholder data in that brief NFC network session. By cardholder data, I am referring to those all-important 16 digits on your credit or debit card as well as some other personally identifiable information necessary to complete the transaction. This means that your card info is still vulnerable to the same types of malware within the retailer’s network that caused breaches like those reported at Target, Kmart and others.
Another issue that arises in this scenario is that the same card information we are afraid to hand over to the retailer is now living on our smartphones. Without proper security (locked screens via passwords or biometrics, phone encryption, remote kill switches), a lost or stolen phone becomes as dangerous and critical as a lost or stolen wallet. At the end of the day, I believe that traditional NFC-based eWallets are not any worse than traditional card-based transactions, but they are also not significantly better.
Now let’s take a moment and explore some of the differences found in Apple’s eWallet solution, Apple Pay. Apple Pay is a tokenized solution meaning that a randomly generated token is passed via the NFC transmission in the place of actual cardholder data. This is possible through Apple’s partnerships with First Data and other banking institutions and merchants. This tokenization process eliminates some of the risk incurred by traversing a retailer’s network that might be infected with malware. The cardholder data is not present in the transmission for the malware to capture.
Also, no cardholder data or transaction data is captured or stored by Apple. Nothing is retained on an Apple server. All card information is stored locally in the iPhone 6 on a separate, heavily encrypted memory partition called Secure Element. Apple doesn’t even know what you bought. Apple Watch will have its own Secure Element storage for implementations of Apple Pay via pairing with the iPhone 4s/5/5s.
Even though Secure Element is present and in use, important information is still located on the iPhone that could still be lost or stolen. Apple Pay can support two-factor authentication for all financial transactions by requiring the use of Touch ID to trigger the payment process. Touch ID is the biometric reader integrated in the home button of all iPhone 5s/6/6Plus devices. This means your finger would need to be present to give value to the lost or stolen device if used for a purchase. Taking that one step further, the use of Apple Pay on lost or stolen iPhones can be remotely disabled using the “Find My iPhone” application.
Let me be clear by saying that all of these differences found in Apple’s implementation do not make it a perfect solution. Though no cardholder data is stored, Apple Pay does require a connection/association to an iTunes/AppleID account, and these accounts have been proven vulnerable over the past several months. Also, Touch ID, as a second factor of authentication, has been proven vulnerable to hacking since its release. Finally, Because of its large user base, Apple in general and Apple Pay specifically will have a huge target on its back at launch. Criminals and white hat and black hat hackers will attempt to find and exploit its weaknesses.
No technical solution deployed for payments will ever be perfect. There are too many factors in play and as humans, we will make mistakes. That said, I do believe there is significant value in a tokenized financial transaction solution, specifically when a second factor of authentication can be brought to bear. I will personally be testing Apple Pay at my earliest convenience and I will report back on my success or failure.