No network is impenetrable, a reality that business executives and security professionals alike must accept. The traditional perimeter focused approach to cybersecurity has often failed to prevent intrusions, especially in an application-focused paradigm.
While prevention is crucial, timely incident detection of anomalous behaviors for data ex-filtration are key. Continuous monitoring assumes the attackers are already inside of the network and using the right tools, data, and strategies to interrupt the attackers communication channels are needed to mount a successful breach.
The advent of Bring Your Own Device (BYOD) has become prevalent and a sound continuous monitoring strategy that can work in this new Internet Service Provider style network will be an essential protection strategy.
Most CISOs in the EDU world have to create an IT security model that works across 3 distinct business environments in a university: Administrative, Academic/Instructional, Research.
The Administrative environment contains the business processes that run the actual University. These include HR, Payroll, Purchasing, PR, among others. These are the same processes that you would find in any business. They require the same cyber defense architecture. We have the same cyber and physical controls as our non-Edu counterparts.
The Academic/Instructional environment provides the Learning Management Systems (LMS), which usually contains functions such as course delivery, grading, content management, grading, and assignment submission. This is where BYOD lives in our world. All students are required to own a computer and they use their computer to access their course materials.
Every August 5000-6000 new computers (an average freshman class) enter our network. Here the security model is similar to that of an ISP. We can’t control what software is installed on a privately owned machine. We can require certain conditions be met before a machine connects to our network. My counterparts in the non-Edu world will be moving to this model in the next few years. Why? C-level executives want that convenience. Younger employees will want this convenience. It’s only a matter of time.
The Research environment is a hybrid of the Administrative and Academic/Instructional environments. Intellectual property (IP) is closely guarded and protected. Researchers need the flexibility to create devices to aid their research. The manufacturing sector is probably closest to this model. There are regulatory requirements that need to be addressed in this environment.
Our challenge is to develop a security model that encompasses the requirements of the Administrative, Academic/Instructional and Research environments. It’s a challenge but one that needs to be met.

The post Will Corporate Security Models Move Toward the EDU Security Model? appeared first on Security Current.

Glenn Fink, a security researcher at Pacific Northwest Labs, did a presentation called the “Internet of Cows” at a recent IEEE conference where he showed how dairy farming has become an automated, internet accessible business process.
He took the discussion one step further by saying that cows make great human surrogates in the privacy debates surrounding IoT. He showed how data from almost every single biological process of a cow (health, reproduction, location, sounds) is monitored by IoT.
Analysis of herd data allows farmers to predict the health of a cow, the optimum time for reproduction and milk production. He maintained that cows don’t object to this type of management and therefore, this is why they are well suited to study the effects of intrusive monitoring.
It was one of those presentations that makes you go “hmmmmm.” The use of “biological” Internet of Things has been well established in the animal husbandry world. As Glenn stated, we’re already moving in this direction with regard to human health monitoring.
The privacy implications of such monitoring should concern most of us these days. I’ve always said that I don’t mind external sites collecting data about me as long as a) the default is opt-out where no data is sent out b) you tell me what you’re going to do with my data c) you protect my data from unauthorized access.  Obviously, this isn’t the norm these days.
Hopefully, as more “fitness” IoT devices enter the market, people will start to demand their health info be safeguarded as much as possible.

Google “The Internet of Cows” to see a lot of articles on this topic. As you read those, remember that most of these bio-monitoring services are available to monitor human health information. More on this later….

The post “The Internet of Cows” appeared first on Security Current.

In my last article, I talked about using the 20 Critical Controls as a practical security strategy.  I showed how the controls map to a wide variety of international and national standards.  I also mentioned a great www site, www.auditscripts.com, where you can download 3 excellent spreadsheets to help you measure your progress in the controls implementation.

I’ve said a border based security strategy (“keep them from coming in”) was a recipe for failure. I do believe the data breaches of the past couple of years support my assertion.  A risk-based approach to security is the most effective strategy for any security program.  It is also the most difficult strategy to implement. An effective cyber defense strategy has four parts:

1. Continuous monitoring ensures current security measures are functioning correctly.
2. Automation allows the organization to obtain continuous measurements of the status of the defense systems.
3. Metrics are an important component of any cyber security strategy. The underlying principle of “if you didn’t write it down, it didn’t happen “uses metrics to measure the effectiveness of installed security measures.
4. Offense informs defense. This may seem counterintuitive but you need to know how to attack the system or network in order to be able to defend it.

Part 1 of this series describes the first 5 of the 20 Critical Controls. In this article, we’ll take a look at the next 5 controls.

Controls 6 – 10

Control six deals with application software security. It doesn’t matter whether the applications are developed locally or by a vendor. Obviously, we have more control over in-house development. It’s important that such software systems build security into their design from the beginning.  We want to neutralize any vulnerability in web-based or other application software.  Application software vulnerabilities give hackers a vector into an organization’s systems.  Software vulnerabilities allow hackers to complete 7 of the 8 steps in the Mandiant Attack Life Cycle:

1.Initial recon

2.Initial compromise

3.Establish foothold

4.Escalate privileges

5.Internal recon

6.Move laterally

7.Maintain presence

This control attempts to provide proactive methods of either preventing such software from being installed on any of your system or mitigating vulnerabilities created by these flaws.

The end-user is made aware of any of these vulnerabilities and may be required to purchase additional controls to address those long abilities. This control ties in with a risk based security strategy.  How? An informed user is the best asset one can have in institutional cyber security architecture.

If the software package is a sole source for a critical business function, it’s going to get purchased/developed and used regardless of security problems.  So, the ISO shouldn’t prevent the acquisition (remember – business need trumps security in today’s climate) BUT must recommend additional controls to address software weaknesses.  Software security questionnaires are one way to determine the security posture of vendor and application software.  Such a questionnaire is available at our VirginiaTech site.

The purpose of the questionnaire is to inform the purchaser of any software security issues with a vendor software package.  One of my favorite sayings is “trust but verify.” The security questionnaire is an example of the “trust” part of the saying.

Running vulnerability scanners, pen test tools against your software applications are the “verify” part of the saying.  I’m a firm believer of running scanners against our own infrastructure. We might as well find out what a potential attacker can find out about us.

Control seven deals with wireless device controls. Wireless networks changed location of the border from defined access paths to the individual device itself. Since it’s relatively straightforward to connect to an internal host via wireless techniques, it is critical that this control addresses how systems connect to the wireless network, how users are identified and where the wireless system is located.

Security engineers sometimes forget wireless networks eventually connect to the wired network. Control 1 (Inventory of Hardware Connected to Your Network) plays an important role in control 6’s implementation.

The challenge with this control is not WHO gets connected to the wireless network. NAC solutions address the authorization and authentication aspects of connection. The challenge is determining WHERE the wireless device is currently located. Wireless by its nature implies mobility and it’s critical that the organization be able to locate a wireless device. Data logging and retention are the only ways one can determine location of wireless devices. How long does your organization retain wireless access point (AP), authentication, DHCP, NAT, and other logs?

Control eight is called data recovery capability and it deals with the methods and strategies used to recover data in the event of an accident or deliberate attack. Things like network backup services organized backups, cloud storage, off-site storage are examples of data recovery capabilities. Proper data recovery techniques mitigate the effects of cryptoware attacks and other ransomware attacks.

I said over the years that poorly trained end-user and system administrators are the biggest threats to any organizations cyber security pot. Control nine investigates what type of security skills assessment and appropriate security training are available to the university community. Examples range from homegrown security presentations, seminars, printed materials to vendor supplied training systems be they online or in house.

Control 10 is similar to control three but it deals with secure configurations for network devices such as routers firewalls switches whereas control three deals with end-user systems. This is one of the most critical controls to have in place because the items in this control protect the network infrastructure. If you lose the network infrastructure to a hacker control, the game is over. Network segmentation, firewall configuration, router configuration, and basic network architecture are examples of components that need to be examined in order to successfully this implement control.

Summary

In this article, we’ve reviewed Critical Controls 6-10. Controls 6 and 7 are particularly important but they are two of the most difficult ones to implement.  Control 6 is needs to be inserted into your company’s purchasing process.  Control 7 helps defenders determine the location of a wireless device. This is important in determining whether you have 1 infected device that is moving around your network or multiple infections.

A good backup process is key to the recovery step of incident response. There’s a reason why professional teams and the military practice constantly. The goal is to do things efficiently and training is one of the most important steps in developing your staff.

We’ll talk some more in part 3 of this series.

The post The 20 Critical Controls – A Practical Security Strategy – Part 2 appeared first on Security Current.

Back in the late 1990’s, I was fortunate to be part of a team of cyber security experts who were asked to develop a list of the Top 10 Internet Security Threats. “On February 15, 2000, thirty Internet experts met with President Clinton to identify actions needed to defeat the wave of distributed denial of service attacks and to keep the Internet safe for continued growth.

“One of the resulting initiatives was a project to develop a community-wide consensus list of the most often exploited vulnerabilities. Forty two people from all parts of the Internet community worked together to reach consensus on the top priority threats.”

The document produced by this group listed 10 Internet Threats that were responsible for over 70% of the successful Internet attacks of the late 1990s.

Fast forward to 2008:

“Surprisingly, the clear consensus of the consortium was that there were only 20 Critical Controls that addressed the most prevalent attacks found in government and industry. This then became the focus for an initial draft document. The draft of the 20 Critical Controls was circulated in early 2009 to several hundred IT and security organizations for further review and comment. Over 50 organizations commented on the draft. They overwhelmingly endorsed the concept of a focused set of controls and the selection of the 20 Critical Controls. These commenters also provided valuable “fine tuning” to the control descriptions.” (http://www.sans.org/critical-security-controls/history)

In a similar vein, the 20 Critical Controls followed the same path as the Top 10 Internet threats document. They provide a blueprint of actionable items that are components of overall operational security architecture. These actionable items help you detect and respond to 60-70% of the attacks seen today.

Organizations have tried to align their security architectures with various international standards (ISO 27001/2, NIST 800-53, Australian Top 35, etc.). Failure to distinguish between “compliance” and “assurance” usually results in security failures with repercussions aimed at upper security management. So, where do we start?

The goals of the Critical Security Controls:

• Those with knowledge of threats & attacks help the groups defending systems as a part of a community risk assessment model to secure systems.
• Defenses should focus on addressing the most common and damaging attack activities occurring today and those anticipated in the near future. Today’s defensive mechanisms should be based on actual attacks. Defenses must be based on tactics that can stop these attacks.
• The Enterprise security architecture must be implemented in a consistent manner across the enterprise. If they are not implemented consistently across the enterprise, then the organization is opening the door for risk.
• Defenses should be automated where possible and periodically or continuously measured using automated measurement techniques where feasible. “Trust but verify” is a must-do goal. Higher backbone speeds allow a tremendous amount of information to potentially be exfiltrated. Automated defenses can mitigate this data transfer but they must be tested and verified frequently.

The 20 Critical Controls are a set of technical controls that can help defend systems. There are other models that focus on process and operational tactics; this is not one of them.

Root cause problems must be fixed in order to ensure the prevention or timely detection of attacks. We are not simply attempting to address surface issues with these controls. We are trying to get to the heart of the issue. More money or more personnel are not always the solution to this problem. There may be other underlying causes that need to be addressed before we start to see success.

Metrics should be established that facilitate common ground for measuring the effectiveness of security measures, providing a common language to communicate about risk.” (James Tarala, Eric Cole)

The 20 Critical Controls are designed to help organizations protect their information systems. These controls are only useful if we take the time to implement and follow them.

I highly recommend doing a gap analysis to measure how your organization’s security architecture maps to the 20 Critical Controls. Asking the following questions helps you determine where the gaps are:

• Where does your organization have deficiencies?
• What are the most important next steps for your organization?
• What evaluation plan will you follow in light of these controls?

Compliance with Established Security Architecture Standards

The Critical Security Controls focuses first on prioritizing security functions that are effective against the latest Advanced Targeted Threats, with a strong emphasis on “What Works” – security controls where products, processes, architectures and services are in use that have demonstrated real world effectiveness.

Standardization and automation is another top priority. The actions defined by the Controls are a subset of the Priority 1 controls defined by the National Institute of Standards and Technology (NIST) SP 800-53.

The Controls focus on a smaller number of actionable controls. Since the Controls were derived from the most common attack patterns and were vetted across a very broad community of government and industry, they serve as the basis for immediate high-value action.

AuditScripts.com is an excellent site created by James Tarala. He developed an spreadsheet showing how the 20 Critical Controls map to the well-known international standards:

• NIST 800-53 rev 4
• NIST Core Framework
• DHS CDM Program
• ISO 27002-2013, 27002-2005
• NSA MNT
• Australian Top 35
• NSA Top 10
• GHCQ 10 Steps
• UK Cyber Essentials
• UK ICO Protecting Data
• PCI DSS 3.0
• FFIEC Examination Handbook
• COBIT 5
• NERC CIP v3, v4, v5
• CSA (Cloud Security Alliance) CCM v3
• FY15 FISMA Metrics
• ITIL 2011 KPIs

I think you’ll agree with me when I say the 20 Critical Controls would satisfy any auditor’s question about compliance with well-known standards. You can download the Critical Security Control Master Standards Mapping (v.5b) spreadsheet along with some other valuable spreadsheets at: auditscripts.

Controls 1-5

In this section and subsequent posts, we’ll review the 20 Critical Controls.

Remember, our focus is ASSURANCE not compliance!

Control 1. Inventory of authorized and unauthorized devices

Reduce the ability of attackers to find and exploit unauthorized and unprotected systems: Use active monitoring and configuration management to maintain an up-to-date inventory.

There’s a commercial that has the slogan “You can’t hack what you can’t see”. (Don’t get me started on this). I would prefer modifying the slogan to be “you can’t defend a) what you don’t know you have b) where it’s located in your network c) who is responsible for maintaining that asset. This isn’t a trivial task because most nets have a lot of ways to connect to their nets. For example, here are some possible connection points:

• Wired, static IP addresses
• Wired, DHCP assigned addresses
• Wired VPN
• Wireless, wireless DHCP, wireless VPN

Devices that connect to your network include mainframes, servers, desktops, laptops, and mobile devices, the “Internet of Things.”

You need to determine all of the possible ways a machine can connect to your network. Here are some possible sources of information to help you determine where your assets are:

• Network management group – The network management group in your organization usually has some sort of database that lists the physical locations of wired hosts. This information is usually kept for diagnostic purposes to help technicians locate a device that is having connection problems.
• Network scanner – the IT Security office, systems group or network management group may run daily scans of your organization’s network listing the number of servers by type. This list of IP addresses used in conjunction with the database mentioned in the previous bullet item gives an “inventory” of systems connected to your network.
• Organization’s Property Inventory group – Every organization has a group that is responsible for maintaining physical inventories of IT equipment. While the information may be outdated, it’s a starting point for building a reasonable IT asset inventory.

Control 2. Inventory of authorized and unauthorized software

Identify vulnerable or malicious software to mitigate or root out attacks: Devise a list of authorized software for each type of system, and deploy tools to track software installed (including type, version, and patches).

With the exception of educational institutions and Internet Service Providers (ISP), most organizations can compile a list of authorized software installed on company IT assets. Individual software purchasing groups are another source of this information along with system administrators’ software inventory lists.

Control 3. Secure configurations for hardware and software on laptops, workstations, and servers

Prevent attackers from exploiting services and settings that allow easy access through networks and browsers: Build a secure image that is used for all new systems deployed to the enterprise.

Configuration checklists for different classes of systems are one of those common sense things that most system administrators do as part of their regular job functions. Specific images aka ISO masters, Gold Disks, or Deep Freeze builds are examples of how you would comply with this control. I’ve seen checklists that include the “authorized ports” that should be open on specific classes of machines. This is a good feature but it does require a lot of work to determine exactly what ports a software product uses.

You can use the Center for Internet Security (CIS) benchmarks and scoring tools to set a verifiable “security” score for the different types of assets in your organization. For example, you would build a base system image then use the appropriate CIS benchmark to harden this system image.

Control 4. Continuous Vulnerability Assessment and Remediation

Proactively identify and repair software vulnerabilities reported by security researchers or vendors: Regularly run automated vulnerability scanning tools against all systems and quickly remediate any vulnerabilities.

This control seems pretty obvious to me for a number of reasons. First, running vulnerability scans against your systems helps you verify your secure configurations created in Control 3.  Second, a vulnerability scan provides a log “signature” on the target system that can help you determine the type of vulnerability scanner being used against your system. Third, this control helps you identify assets in your network (Control 1).

Control 5. Malware Defenses

Block malicious code from tampering with system settings or contents, capturing sensitive data, or spreading.

There are tons of classes of malware out there. From my perspective, the most dangerous classes of malware are the info stealer, downloader and keylogger classes. Info stealer malware searches the victim computer for any personally identifiable information (PII) such as social security number (SSN), bank/credit/debit account numbers, driver’s license numbers, and passport numbers. It compiles a list of files containing PII and prepares to upload them to a drop box system or CnC controller. Downloader malware makes the victim a temporary drop site for other malware or stolen data. Keylogger malware installs keylogging software on the victim machine to capture authentication information.

So, you should install appropriate malware defenses such as malware detection engines (FireEye, Damballa, etc.) or other host based software on critical assets or assets that may store PII or critical company intellectual property. Once installed, you need to set up a log analysis infrastructure using big data techniques to quickly provide your analysts with the information needed to respond to the malware attack. You should use this control to help you detect any exfiltration of sensitive data such as PII or intellectual property.

Summary

In this part, I’ve given you an introduction to the 20 critical controls, the motivation behind them and how they can help you comply with the various international security architecture standards. I’ve described briefly the first 5 controls and where you can get some information on how to implement them. In the next three parts, I’ll go over the remaining 15 controls. As always, I welcome any comments you may have.

The official home of the Critical Security Controls is the Council on Cybersecurity. The CEO of this effort is Jane Lute, the former Deputy Secretary of the US Department of Homeland Security. This not for profit group’s stated mission is:

“The Council on CyberSecurity is an independent, global organization committed to an open and secure Internet. We contribute to this vision by mobilizing a broad community of stakeholders who are willing to bring their knowledge, experience, and commitment to a common goal: to identify, validate, promote, and sustain the adoption of cybersecurity best practice – by people, with technology, and through policy – to create a world in which best practice becomes common practice.”

The Critical Security Controls is simply one of many cybersecurity projects managed by this council. The Critical Security Controls themselves are managed by Tony Sager, formerly of the US National Security Agency, and a board of advisors and volunteers. This is the group that manages the actual documentation and updates to the controls themselves.

The post The 20 Critical Controls – A Practical Security Strategy – Part 1 appeared first on Security Current.

When you’re on a roll, ride it out. I’ve been on the “Redux” train for a couple of days. I usually do this when I review our security architecture initiatives at the end of the year.

Way back in 2000, I said in a USA Today interview that it wouldn’t surprise me if there were product liability lawsuits against software vendors because their code had simple well known errors that could cost customers like you and I a lot of money and loss of reputation. I regret making that statement but not for the reasons you may think.

My thought was that software vendors would start fixing their code by removing well-known software vulnerabilities. What happened was the End User License Agreements (EULA) were modify to absolve the vendor of any damages caused by their product or limiting the damage to the amount of the purchase cost of the software product. Read the EULA of software purchase by your company to see if such a clause exists.

All is not lost. Some software vendors have made good faith efforts to fix as many errors as possible in their products. Certainly the OS vendors (Windows, Mac OSX, Unix/Linux) have made tremendous strides in eliminating vulnerabilities from their OS products. Application software vendors are slower in responding.

It’s time for us to understand what vulnerabilities may be present in a vendor application before it bites us. Application security questionnaires are a good first step in helping you determine what other compensating controls you may need to purchase. Take a look at brief to see an example of such a questionnaire.

This form is sent to the vendor as part of the purchase process. The results are analyzed by the IT security office that then passes a recommendation to the purchaser. The recommendation may range from a) the product looks ok to b) you can buy the product but you will need to purchase additional hardware or software to protect your sensitive data.

Our intent is not to prevent a department from buying a software package but to inform them of the risks of using such a package.

Some vulnerabilities like SQL Injection, Cross Site Scripting have been around for almost 6 or 7 years. Why are they still in software products created in 2014?  Why are we still buying such products?

Here’s a great little presentation on the top 5 application errors. As a disclaimer, I’m not associated in any way with Veracode.

See you next time.

The post Application Security – Redux appeared first on Security Current.

Yep, it’s time to use this title again. This time we’re talking about Distributed Denial of Service (DDoS) amplification attacks. One of the lists I monitor posted the following:

Christian Rossow has done some great work on DDoS.  The two interesting papers are:
“Exit from Hell? Reducing the Impact of Amplification DDoS Attacks,” read here.

The authors also look at DNS, NTP, SNMP, SSDP, CharGen, QOTD and NetBIOS. The last sentence of this paper, “We measured almost 46 million amplifiers for all scanned UDP-based protocols.”

“Hell of a Handshake: Abusing TCP for Reflective Amplification
DDoS Attacks,” read here.

The quote from the Kuhrer paper is a depressing read:

“The basic idea is to send relatively small requests with spoofed source address to public hosts (e.g., NTP servers), which reflect significantly larger responses to the victim of the attack.”

Why? In 2000, I was part of a Fed/SANS Institute Task Force that wrote a Consensus Roadmap to defeating DDOS attack doc. In there, we stressed the importance of setting your (the collective your) network ingress/egress filters correctly in order to prevent spoofed packets from leaving your network.

The above quote says to me that we’ve (the collective we) has forgotten this basic defense technique. So, my question to the list is “have you set your ingress/egress filters on ALL of your network devices to prevent spoofed packets from leaving your nets. If so, you’ve taken a giant step in reducing the impact of an amplification attack.

The weird sense of humor in me says that the admins who were around in 2000 and set their filters have moved on or retired and their replacements looked at those ACLs and said “WTF? Let’s take these out.”

It’s been 14 years now and spoofed packets are still an issue.

I’m just saying…:-)

The post Deja Vu All Over Again – DDoS Amplification Attacks appeared first on Security Current.

Ok, I know the title sounds a little negative. I’m not against cloud services at all. We use cloud services here for a wide variety of business and personal purposes.

Having said that, there are a couple of issues that bother me about the cloud and while some are philosophical, some are technical as well. One thing that bugs me about the push to the cloud is it’s being touted as some “new” technology.  It’s not.

We’ve been operating in a “cloud” environment since the dawn of computing. The only difference is the “cloud” was inside our network borders aka a “private cloud.”

Other “advantages” include collaborative tools that allow people to access files (hmmm old school NFS) and modify them to increase productivity; economic advantages of saving $$ thereby allowing your company to be “green” and do its part for sustainability.  Another claimed advantage is the transference of risk to the cloud provider instead of your company.  All of these are valid points. Here are some things to consider.

1. Sustainability – this is very good. But the fact of the matter is that power to run the cloud storage units is consumed somewhere else so what is the net savings of energy if you look at the whole picture? Probably negligible since the cloud services has to consume power to function.

2. Collaborative tools – This is certainly true. Products like Google Apps and SharePoint Online are examples of some great collaborative tools. Whether they actually increase productivity depends on your organizational culture. In the EDU world, you probably can demonstrate gains on the academic/research side of the house. I’m not sure about the administrative or business side of the house. In the corporate world, internal politics may actually discourage collaboration.

3. Ask yourself this question. Would you store your personal tax records, wills, deeds, vehicle titles, and photos at a remote site not knowing exactly WHERE these sites are? To some degree, we do this already. It’s called a bank safe deposit box. You put your valuable documents in some safe location outside of your home in case of a local disaster.  An regional disaster like Hurricane Katrina may invalidate that assumption but those scenarios are thankfully rare. At least I hope so. Can you get to your sensitive data WHEN you need to get to your sensitive data?

4. Have they ever suffered a data breach? I know, good luck getting an answer to that one. Remember, however, that Google, Yahoo and other major Internet giants have suffered data breaches in the past.

Why would a company want to store their business records, customer data, intellectual property etc. with another company?

What do you know about these companies? We used to say “they’re big and they can be trusted.” I think the Snowden disclosures have cast a “cloud” (pun intended) on some of the Internet “giants'” reputations for safeguarding your data. The CEO of one of the major Internet giants said that they were “forced” to cooperate with the government or else the CEO would go to jail.

www.cloudsecurityalliance.org has a great set of guidance documents to help you do a reasonable risk analysis of cloud services. Take a look at the Cloud Controls Matrix or the Security Guidance for Critical Areas of Focus in Cloud Computing v3.0 guides. The Security Guidance doc is especially useful because it lists 13 “domains” that should be discussed with a cloud provider during contract negotiations.

The domains include Governance & Risk Management, Information Management and Security, Incident Response, Application Security, Encryption and Key Management and Traditional Security, Business Continuity and Disaster Recovery. These are areas you should ask the cloud provider how THEY do these things.

For example,  if you decide to terminate your contract with a cloud provider, how long does it take them to remove ALL instances of your data including backups and do they notify you that they have done this? I’ve found these  guides to be very useful in building a cloud-based data protection strategy.

Let’s face it. It’s all about the data. Public information about your organization stored in the cloud isn’t as risky as storing personally identifiable information (PII). While we’re on that subject, let’s talk about encryption in the cloud.

You should ALWAYS encrypt any sensitive data files before storing them in ANY public or private cloud. State data breach notification laws, Federal export restricted data governed by ITAR or DFAR must reside on servers physically resident in the continental US. Does the cloud provider guarantee this? Some do, some don’t. Some cloud providers will encrypt the data files once they’re stored on their sites. Make sure you know who owns the encryption keys.

Some data should never be stored in a cloud outside of your network borders.  You need to do a thorough and comprehensive risk analysis to determine the risk of data exposure in the cloud. I strongly recommend you read the docs at the cloudsecurityalliance.org www site before you finalize a contract with a cloud storage provider.  Remember, there’s always a price you pay for convenience.

The post Cloud Security: How I Learned to Love a Data Exfiltration Service appeared first on Security Current.

Ok, maybe it’s not a marriage but more along the lines of living together.

In a previous article, I spoke about moving to a Continuous Monitoring security model, which focuses on monitoring outbound traffic.

As we move to completing our monitoring infrastructure, I’ve been pleased with the results so far and excited by the challenges discovered by the process.  One of the things that surprised me was how Continuous Monitoring is forcing a cultural change between the Security Office and the Network Management group.

It all comes down to sharing data which depending on your institutional culture can be either challenging or really challenging.

Here are 2  things that significantly impacted progress in our project:

• Network backbone line speeds can significantly impact your inline packet capture and monitoring techniques. If you network group upgrades your backbone speeds to 100Gb, there aren’t a lot of IDS/IPS network interfaces that can operate at those speeds.  A network upgrade can blind your sensors inadvertently.
• New network management tools can blind your deep packet inspection tools. Specifically, MPLS ( Multi Protocol Label Switching) breaks traditional packet capture tools. How? MPLS encapsulates traditional IP packets which basically assigns a packet a distinct label.  It makes perfect network management sense to use MPLS to manage a large, complex network. It complicates IDS/IPS packet monitoring because most of these devices currently don’t know how to decode an MPLS encapsulated packet. For example, if you are using Gigamon network switches, you’ll need to buy a special line interface card that strips off the MPLS header. This is not a cheap feature.

Wireless network infrastructure logs are quite frankly, huge. Identifying who’s on a wireless network requires careful planning and collaboration with the network management who traditionally collects the required logs.

IT Security Offices need to establish good working relationships with their organization’s network management groups. Network management groups need to be aware that traditional network upgrades can significantly impact a security office’s intrusion detection initiatives. Some of these impacts can add significant dollars to a security project.

The post Announcing the Marriage of the IT Security Office and the Network Management Group appeared first on Security Current.

One of the most difficult decisions a CISO has to make is the one that says the organization suffered a data breach.

A data breach starts a chain of events that could eventually result in loss of company reputation, financial expenditures for credit monitoring of affected individuals, and possible regulatory and legal fines.

Not surprisingly, the CISOs want to ensure they have the latest information before they begin the long journey to the CEO’s office.

Let’s break down the sequence of events that have to happen.

1. It’s not a breach unless it leaves your network :-). While this may sound silly, this simple statement implies a lot of things that should be done ahead of time before it gets to this point. Here are some of the things that you should have in place in order to mitigate your data leaving your network:

• Do you have an efficient software patching system(s) that is implemented on all assets? In particular, why is this important? A successful malware installation depends on a couple of things: 1) a software package with vulnerability present on the target 2) the software isn’t patched. Patching reduces the attack window.
• Does your defense strategy focus on what leaves your net rather than what enters your net? There are 3 phases to a successful compromise:
• Initial compromise: this phase is completed by exploiting a known weakness in a software package that usually hasn’t been patched.
• Maintaining access to the compromised host: attackers need to maintain control of the victim machine by setting up local accounts, rootkits and covert communications channels.
• Causing damage: this is where attackers damage the organization by stealing, altering, or destroying information, impairing the system’s functionality to jeopardize its business effectiveness or mission, or using it as a jumping-off point for compromise of other systems in the environment. (source: James Tarala, Eric Cole)
• A compromised system has to communicate with an external site in order to let the attackers know the malware installation was successful. Building a profile of where your systems that handle PII communicate (this isn’t easy) is an important step in this detection process. A communication to an “unusual” site could be an indicator of a compromise.
• Do you know where your PII is stored? There are freeware (Find_SSN, Spider, SENF) and commercial (IdentityFinder) PII search tools that hunt for PII on your computers. The adage “you can’t protect it if you don’t know where it is” rings true in this case. Are your PII machines spread out all over your net or are they concentrated in protected enclaves?
• Is your PII encrypted? The recent controversy with TrueCrypt caused a lot of turmoil in the security community. There are 2 fairly straightforward encryption solutions that can be adopted across most enterprises. Microsoft Office’s encryption feature actually works in versions 2007 and newer. It requires a password but it solves the email attachment issue and doesn’t require anything extra on the receiver’s side. See http://office.about.com/od/MicrosoftOffice/ht/Encrypt-A-Microsoft-Office-Document-With-A-Password.htm for details. The disadvantage of this solution is that it only works with Microsoft Office documents. PDF Portfolio provides another encryption solution and it’s able to handle just about any file type. It can use passwords or certificates for encrypting/decrypting files.

There are certainly more things that an institution can implement in their security architecture but I believe the ones mentioned above are critical.

Here’s a sample process for determining if a breach has occurred provided the steps above are implemented.

1. Monitor your net for suspicious outbound traffic.
2. Sensors detect an outbound transmission to a suspicious domain. It determines the infection is an info-stealing class of malware.
3. The target machine is located and isolated from the net.
4. Was there any PII on the machine? No: wipe and reinstall the machine with updated software. Go to step 1. Yes: Was the PII encrypted at the time of the infection? Yes: wipe and reinstall the machine. Go to step 1 No: Go to step 5.
5. Determine the size of the files containing PII. Determine the number of outbound packets from the infected machine. PII file size > # of outbound bytes? Yes: good chance there was no exfiltration. No: Good chance there was an exfiltration so start the data breach notification process.

We’ll talk about these steps in more detail in subsequent posts.

The post When is it a Breach? appeared first on Security Current.

You almost have to be on some deserted island with no Internet access to have not heard about the OpenSSL Heartbleed vulnerability. This vulnerability is very serious and pervasive because of a few simple reasons:

1) it allows attackers to be able to dump a target’s memory which can include among other things, usernames/passwords, emails currently opened by an email client, private and secondary OpenSSL keys/certificates or data being accessed by programs running on the target system 2) the OpenSSL library with the bug is free, therefore, it’s on a LOT of systems on the internet 3) there is no log of an attacker accessing a site 4) the bug was recently discovered but has been around since 3/2012.

It’s obvious that capturing a username and password is not a good thing but the ability to capture the private and secondary OpenSSL keys means that the attacker has the ability to decrypt SSL traffic between the client and the server. Since items transmitted from client to server via these encrypted streams usually include sensitive information such as bank or debit account numbers, credit card numbers (CCN), social security numbers (SSN), you can see why security professionals are worried.

The bug was simple. Heartbleed is a play on the term “heartbeat”. A “heartbeat” is simply a communication between 2 systems letting each other know they’re still alive (connected). For example, a web client would send a heartbeat to a web server by sending a string of characters and asking the server to send them back to the client.  The client sends a string and the length of the string being sent. The length figure can be up to 64 KB.  Normally, the server would echo back the string. A sample transaction might look like this from a high level:

1. Client to Server: I’m sending you 5 characters ABCDE

2. Server to Client: I’m sending you those 5 characters ABCDE back.

The OpenSSL function that does this is supposed to send the correct length string but (here we go) if you say “I’m sending a 64KB length string then send just one byte, the server would send back 64KB of memory data. What’s in the remaining 64KB-1 bytes that came back to the client? Any number of things including usernames, passwords, etc.

You’re probably thinking, “Why didn’t they include a check to make sure your length and actual length fields matched?” Well, the authors were asking the same question. That was the bug.

What Should My Response Be?

It’s the answer every CISO hates: “it depends”.  First, you have to scan your net to see if you had any vulnerable systems running OpenSSL v1.0.1-v1.0.1f. If you did, then you need to determine what function your server performs. If your server handled user authentication, there’s the possibility that user credentials may have been copied. An appropriate response would be to fix the systems, verify the fixes and then force a password reset for all user accounts.

Here’s where the “it depends” answer makes your life miserable. There’s no way to prove that user credentials or any other items in the server’s RAM were copied. You’re forced to act in a “better safe than sorry” mode.  

Mashable lists some of the major Internet services that were affected by Heartbleed. Most of the major services suggested you change your passwords to be “better safe than sorry”.  We decided to be “better safe than sorry” and forced a password reset at our site. As of this date, 43K users have changed their passwords. We started a PR campaign telling our user community that they had to change their passwords. We enlisted our Public Relations group, the various groups in charge of the technical aspects of mitigation, the Help Desk and of course, upper management approval.

One pleasant surprise was the speed of an affected sysadmin’s response. When we first scanned our net, we found ~480 systems with the Heartbleed vulnerability. Within 24 hours, that number went to ~220 systems. After 5 days, there were ~48 systems left. These systems were embedded systems waiting for a vendor patch to be created. The sysadmin community’s response was exemplary and helped tremendously to contain the threat.

Here are some links that contain some useful information about Heartbleed:

http://xkcd.com/1354/ – a great XKCD cartoon that explains how heartbleed works
http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/ – the Heartbleed hit list. Contains a list of common Internet services (Gmail, Hotmail, banking sites, etc.) and whether they were affected and the response to the vulnerability. This is a “Must Read”.

http://www.heartbleed.com – technical description of the bug.

The post Heartbeat, Heartbleed or Heartache? appeared first on Security Current.