Bell Labs, the Colonial Pipeline and Multi-Factor Authentication (MFA)

A simple technology invented by Bell Labs over 20 years ago (and widely used today) could have prevented the Colonial Pipeline attack.

In 1880, the French government awarded Alexander Graham Bell roughly the equivalent of $300K as a prize for inventing the telephone. He used the award to fund the research laboratory that became colloquially known as Bell Labs. If you’re not familiar with Bell Labs, you should be. In the 140+ years that followed, researchers at Bell Labs invented radio astronomy, transistors, lasers, solar cells, information theory, and UNIX, just to name a few of the many accomplishments. Among the many prestigious awards granted to Bell Labs researchers are nine Nobel prizes and twenty-two IEEE Medals of Honor.

In 1998, I joined AT&T Labs, which was a research group that the company retained when they spun out most of Bell Labs to Lucent Technologies in 1996. I was a Web Application developer; one of the least technical roles in the Labs. If I ever thought for a moment that I knew technology, I was quickly humbled when I built an app that tracked the Labs' actually important projects. The experience of working in the Labs stuck with me in the form of humility and curiosity. I accepted that I may never be the foremost expert in any given technology and I assumed the mindset of a forever student. Even today, I constantly question what I think I know because there are always holes in my knowledge or perspectives that I haven’t seen.

1998 was the same year that researchers at AT&T Labs were issued a patent (filed in 1995) for what became known in our industry as Multi-Factor Authentication (MFA). As a Product Manager at a tech firm, I don’t review patents for legal reasons. But I recently saw an excerpt of the abstract for the AT&T patent and there was one line that I found entertaining: “A preferred method of alerting the customer and receiving a confirmation to authorize the transaction back from the customer is illustratively afforded by conventional two-way pagers.” Not much has changed in 23 years. Pagers have been largely replaced by SMS but text messaging through the telecom provider’s network remains one of the most popular delivery mechanisms for MFA (despite some potential security flaws). 

I have no personal insight into AT&T’s motivations at the time, but I read Kevin Mitnick’s book a few years ago (Ghost in the Wires) and can’t help but wonder if AT&T was at the forefront of developing security technologies because they were such a target of hackers for so many years. I also reached out to Steve Greenspan, one of the inventors named in the patent to get his thoughts on the project. He noted:

"Two-way pagers had just come out (1994-1995), and our cybersecurity friends were debating whether quantum computing would undermine password-based security. The goal was to explore business applications for two-way pagers and to put humans in-the-loop for secure access."

Quantum computing is a a pretty interesting business driver for MFA, especially in the mid-1990's. The concern is even more relevant today as we inch closer to quantum compute becoming a practical reality. Today's authentication systems should store password data in non-reversible hashes (theoretically preventing the quantum threat), but it's clear that credentials are being stolen all the time (often via large databases that are just left unprotected) and MFA remains a top solution to mitigate the damage. Steve and team were clearly on the right track when they dreamed up out-of-band authentication and deserve some credit and recognition for the foresight.

You may be wondering how this relates to the pipeline attack that led to fuel shortages across the U.S. East Coast. Bloomberg reported that the Colonial Pipeline, which is the largest fuel pipeline in the country, was taken down by a single compromised password. That should never happen given the variety of tools available to limit and control access, starting with MFA – a relatively simple solution that would likely have prevented the attack. The entry point to the system was a Virtual Private Network (VPN) account. If you’re using a VPN and expose anything sensitive inside the VPN, you should implement strong authentication that includes at least two authentication factors (something you know, something you have, something you are). These are widely available technologies that are very effective against lost or stolen credentials.

Of course, authentication isn’t the end of the story. Today’s widely distributed and highly dynamic environments require multiple layers of security. We all know how popular email and phishing attacks have become. It only takes one person inside a network to open an email, click a link, or logon to a phishing site to give an adversary a foothold in the network. We have to assume that will happen and build layers of strong security between any one user and the potential targets.

To illustrate the point, here’s a quick example:

Grocery stores who sell small, high-value items have traditionally struggled with theft. (Ask me over a beer sometime about how I helped take down a recurring thief when I worked at a grocery store.) If the only answer was to authenticate users (check ID) on the way into the store, it wouldn't be enough. Once inside, someone can still pocket items and walk out without paying. If you walk into a grocery store today, you’ll see cameras in the healthcare aisle where small, expensive medications line the shelves. But that’s not enough either. Each item is also locked in an anti-theft device that’s removed at the register. And some items are found in a locked cabinet that requires employee assistance. Theft still happens, but each layer reduces the risk. Our IT environments are much more complicated in terms of the various pathways to theft and our responses to reduce risk typically require more than a few layers of security.

Sensitive data should only be stored in a secure area of the network with access controls and Least Privilege enforcement. Access should be limited to specific hosts or networks. Data should be encrypted (inside the file when possible - so if the file is stolen, the data is still unusable). There should be strong authentication to get into the network and monitoring of all activity. There should be alerts on unusual behavior and Data Loss Prevention (DLP) to evaluate the sensitivity of data moving across the network. The environment should be scanned regularly for vulnerabilities and misconfigurations. And on and on. Any one of these security mechanisms alone is not enough. This multi-layered approach to security is critical in developing a strong security posture that minimizes risk.

We could argue about where to start or which security controls are most important. But, it seems like a no-brainer to implement MFA for employees accessing corporate data and applications. Microsoft, who deals with 300 million fraudulent sign-in attempts daily concluded that “MFA can block over 99.9 percent of account compromise attacks.” That sounds about right. While targeted attacks have increased in prevalence, most attacks are not targeted at specific companies or individuals. Most start with automated scripting or broad-scale phishing attacks that span across potentially thousands of companies and/or millions of people at the same time. When a foothold is found (a script finds a vulnerability or an open port, a user enters credentials into the phishing site, etc.), the attack begins. Implementing a few simple security technologies like automated vulnerability scanning and MFA can prevent most attacks before they begin. Even if a sophisticated phishing attack succeeds despite MFA, the credentials will not be very useful beyond the initial session (which should be limited in scope by other controls).

No single technology will solve all cybersecurity problems. But, implementing MFA is low-cost, easy-to-implement, and highly effective. It may even make life easier for end-users. Password requirements can be loosened because there’s less risk associated with cracked passwords. And there are numerous implementations of passwordless authentication that, while they may not always meet the strict definition of MFA, provide similar (sometimes higher) levels of security as MFA without requiring a password. Combined with context-aware adaptive security (that verifies device, network, location, time-of-day, etc.), these passwordless authentication options may provide the right level of balance between security and user experience. At this point, this isn’t scare tactics or FUD. Attacks on National infrastructure or other high-profile targets can impact the lives of millions with a single execute command. MFA is an easy layer to add to improve security and it’s commonly included with authentication solutions, so there’s really no excuse. It’s time to get it done.

Addressing the Cloud Security Readiness Gap

Cloud security is about much more than security functionality. The top cloud providers all seem to have a capable suite of security features and most surveyed organizations report that they see all the top cloud platforms as generally secure. So, why do 92% of surveyed organizations still report a cloud security readiness gap? They’re not comfortable with the security implications of moving workloads to cloud even if they believe it’s a secure environment and even if the platform offers a robust set of security features. 

Two contributing factors to that gap include:

• 78% reported that cloud requires different security than on-prem. With security skills at a shortage, the ability to quickly ramp up on a new architecture and a new set of security capabilities can certainly slow progress.
  
• Only 8% of respondents claimed to fully understand the cloud security shared responsibilities model; they don’t even know what they’re responsible for; never mind how to implement the right policies and procedures, hire the right people, or find the right security technologies.

I recently posted about how Oracle is addressing the gap on the Oracle Cloud Security blog. There's a link in the post to a new whitepaper from Dao Research that evaluates the cloud security capabilities offered by Amazon AWS, Google Cloud Platform, Microsoft Azure, and Oracle Cloud Infrastructure.

Oracle took some criticism for arriving late to the game with our cloud infrastructure offering. But, several years of significant investments are paying off. Dao's research concludes that “Oracle has an edge over Amazon, Microsoft, and Google, as it provides a more centralized security configuration and posture management, as well as more automated enforcement of security practices at no additional cost. This allows OCI customers to enhance overall security without requiring additional manual effort, as is the case with AWS, Azure, and GCP.”

A key take-away for me is that sometimes, the competitive edge in security in delivered through simplicity and ease of use. We've heard over and over for several years that complexity is the enemy of security. If we can remove human error, bake-in security by default, and automate security wherever possible, then the system will be more secure than if we're relying on human effort to properly configure and maintain the system and its security.

Click here to check out the post and the Dao Research whitepaper.

Hyperbole in Breach Reporting

While reading the news this morning about yet another successful data breach, I couldn't help but wonder if the hyperbole used in reporting about data breaches is stifling our ability to educate key stakeholders on what they really need to know.

Today's example is about a firm that many rely on for security strategy, planning, and execution. The article I read stated that they were "targeted by a sophisticated hack" but later explains that the attacker compromised a privileged account that provided unrestricted "access to all areas". And, according to sources, the account only required a basic password with no two-step or multi-factor authentication. That doesn't sound too sophisticated, does it? Maybe they brute-forced it, or maybe they just guessed the password (or found it written down in an office?)

It reminded me of an attack on a security vendor back in 2011. As I recall, there was a lot of talk of the sophistication and complexity of the attack. It was called an Advanced Persistent Threat (and maybe some aspects of it were advanced). But, when the facts came out, an employee simply opened an email attachment that introduced malware into the environment - again, not overly sophisticated in terms of what we think a hack to be.

The quantity, availability, and effectiveness of attack techniques are enough to make anyone uncomfortable with their security posture. I previously wrote about a German company who, in a breach response, wrote that it is "virtually impossible to provide viable protection against organized, highly professional hacking attacks." CISOs are being told that they should expect to be breached. The only questions are about when and how to respond. It makes you feel like there's no hope; like there's no point in trying.

However, if you look at the two examples above that were described as highly sophisticated, they may have been avoided with simple techniques such as employee education, malware detection, and multi-factor authentication. I don't mean to over-simplify. I'm not saying it's all easy or that these companies are at-fault or negligent. I'm just calling for less hyperbole in the reporting. Call out the techniques that help companies avoid similar attacks. Don't describe an attack as overly sophisticated if it's not. It makes people feel even more helpless when, perhaps, there are some simple steps that can be taken to reduce the attack surface.

I'd also advocate for more transparency from those who are attacked. Companies shouldn't feel like they have to make things sound more complicated or sophisticated than they are. There's now a growing history of reputable companies (including in the security industry) who have been breached. If you're breached, you're in good company. Let's talk in simple terms about the attacks that happen in the real world. An "open kimono" approach will be more effective at educating others in prevention. And again, less hyperbole - we don't need to overplay to emotion here. Everyone is scared enough. We know the harsh reality of what we (as security professionals) are facing. So, let's strive to better understand the real attack surface and how to prioritize our efforts to reduce the likelihood of a breach.

Encryption would NOT have saved Equifax

I read a few articles this week suggesting that the big question for Equifax is whether or not their data was encrypted. The State of Massachusetts, speaking about the lawsuit it filed, said that Equifax "didn't put in safeguards like encryption that would have protected the data." Unfortunately, encryption, as it's most often used in these scenarios, would not have actually prevented the exposure of this data. This breach will have an enormous impact, so we should be careful to get the facts right and provide as much education as possible to law makers and really to anyone else affected.

We know that the attack took advantage of a flaw in Apache Struts (that should have been patched). Struts is a framework for building applications. It lives at the application tier. The data, obviously, resides at the data tier. Once the application was compromised, it really doesn't matter if the data was encrypted because the application is allowed to access (and therefore to decrypt) the data.

I won't get into all the various encryption techniques that are possible but there are two common types of data encryption for these types of applications. There's encryption of data in motion so that nobody can eavesdrop on the conversation as data moves between tiers or travels to the end users. And there's encryption of data at rest that protects data as it's stored on disk so that nobody can pick up the physical disk (or the data file, depending on how the encryption is applied) and access the data. Once the application is authenticated against the database and runs a query against the data, it is able to access, view, and act upon the data even if the data was encrypted while at rest.

Note that there is a commonly-applied technique that applies at-rest encryption at the application tier. I don't want to confuse the conversation with too much detail, but it usually involves inserting some code into the application to encrypt/decrypt. I suspect that if the application is compromised then app-tier encryption would have been equally unhelpful.

The bottom line here is that information security requires a broad, layered defense strategy. There are numerous types of attacks. A strong security program addresses as many potential attack vectors as possible within reason. (My use of "within reason" is a whole other conversation. Security strategies should evaluate risk in terms of likelihood of an attack and the damage that could be caused.) I already wrote about a layered approach to data protection within the database tier. But that same approach of layering security applies to application security (and information security in general). You have to govern the access controls, ensure strong enough authentication, understand user context, identify anomalous behavior, encrypt data, and, of course, patch your software and maintain your infrastructure. This isn't a scientific analysis. I'm just saying that encryption isn't a panacea and probably wouldn't have helped at all in this case.

Equifax says that their "security organization was aware of this vulnerability at that time, and took efforts to identify and to patch any vulnerable systems in the company's IT infrastructure." Clearly, humans need to rely on technology to help identify what systems exist in the environment, what software is installed, which versions, etc. I have no idea what tools Equifax might have used to scan their environment. Maybe the tool failed to find this install. But their use of "at that time" bothers me too. We can't rely on point-in-time assessments. We need continuous evaluations on a never ending cycle. We need better intelligence around our IT infrastructures. And as more workloads move to cloud, we need a unified approach to IT configuration compliance that works across company data centers and multi-cloud environments.

100% protection may be impossible. The best we can do is weigh the risks and apply as much security as possible to mitigate those risks. We should also all be moving to a continuous compliance model where we are actively assessing and reassessing security in real time. And again... layer, layer, layer.

Layered Database Security in the age of Data Breaches

We live in a time of daily breach notifications. One recently affected organization in Germany put out a statement which said: "The incident is not attributable to security deficiencies." and "Human error can also be ruled out." They went on say that it is "virtually impossible to provide viable protection against organized, highly professional hacking attacks." It's a tough climate we find ourselves in. It  just feels too hard or impossible at times. And there's some truth to that. There are way too many potential attack vectors for comfort.

Many breaches occur in ways that make it difficult to pinpoint exactly what might have prevented it. Or, the companies involved hide details about what actually happened or how. In some cases, they lie. They might claim there was some Advanced Persistent Threat on the network when in reality, it was a simple phishing attack where credentials were simply handed over.

In one recent case, a third party vendor apparently uploaded a database file to an unsecured Amazon AWS server. A media outlet covering the story called out that it was not hacking because the data was made so easily available. Numerous checkpoints come to mind that each could have prevented or lessened the damage in this scenario. I’d like to paint a picture of the numerous layers of defense that should be in place to help prevent this type of exposure.

Layer 1: Removing Production Data

The data should have been long removed from the database.

Assuming this is a non-production database (and I sure hope it is), it should have been fully masked before it was even saved as a file. Masking data means completely removing the original sensitive data and replacing it with fake data that looks and acts real. This enables safe use of the database for app development, QA, and testing. Data can be masked as it’s exported from the production database (most secure) or in a secure staging environment after the initial export. Had this step been done, the database could safely be placed on an insecure AWS server with limited security concerns because there’s no real data. An attacker could perhaps use the DB schema or other details to better formulate an attack on the production data, so I’m not recommending posting masked databases publicly, but the risk of data loss is severely limited once the data is masked.

Layer 2: Secure Cloud Server Configuration

The researcher should never have been able to get to the file.

A security researcher poking around the web should never have been able to access this database file. Proper server configuration and access controls should prevent unauthorized access to any files (including databases). In addition to documenting proper security configuration, certain Cloud Security Access Brokers can be used to continuously monitor AWS instances to ensure that server configurations match the corporate guidelines. Any instances of configuration drift can be auto-remediated with these solutions to ensure that humans don’t accidentally misconfigure servers or miss security settings in the course of daily administration.

Layer 3: Apply Database Encryption

Even with access to the database file, the researcher should not have been able to access the data.

At-rest data encryption that is built into the database protects sensitive data against this type of scenario. Even if someone has the database file, if it were encrypted, the file would essentially be useless. An attacker would have to implement an advanced crypto attack which would take enormous resources and time to conduct and is, for all intents and purposes, impractical. Encryption is a no-brainer. Some organizations use disk-layer encryption, which is OK in the event of lost or stolen disk. However, if a database file is moved to an unencrypted volume, it is no longer protected. In-database encryption improves security because the security stays with the file regardless of where it’s moved or exported. The data remains encrypted and inaccessible without the proper encryption keys regardless of where the database file is moved.

Layer 4: Apply Database Administrative Controls

Even with administrative permissions to the database, the researcher should not have been able to access the sensitive data.

I’m not aware of similar capabilities outside of Oracle database, but Oracle Database Vault would have also prevented this breach by implementing access controls within the database. Database Vault effectively segregates roles (enforces Separation of Duties) so that even an attacker with DBA permissions and access to the database file and encryption keys cannot run queries against the sensitive application data within the database because their role does not allow it. This role-based access, enforced within the database, is an extremely effective control to avoid accidental access that may occur throughout the course of daily database administration.

Layer 5: Protect Data Within the Database

Even with full authorization to application data, highly sensitive fields should be protected within the database.

Assuming all of the other layers break down and you have full access to the unencrypted database file and credentials that are authorized to access the sensitive application data, certain highly sensitive fields should be protected via application-tier encryption. Social Security Numbers and Passwords, for example, shouldn’t be stored in plain text. By applying protection for these fields at the app layer, even fully authorized users wouldn’t have access. We all know that passwords should be hashed so that the password field is only useful to the individual user who enters their correct password. But other fields, like SSN, can be encrypted at the app layer to protect against accidental exposure (human error), intentional insider attack, or exposed credentials (perhaps via phishing attack).

Maybe the vendor didn’t follow the proper protocols instituted by the organization. Maybe they made a human error; we all make mistakes. But, that’s why a layered approach to database security is critical on any database instances where sensitive production data resides. Security protocols shouldn’t require humans to make the right decisions. They should apply security best practices by default and without option.

Assuming this was a non-production database, any sensitive data should have been fully masked/replaced before it was even made available. And, if it was a production DB, database encryption and access control protections that stay with the database during export or if the database file is moved away from an encrypted volume should have been applied. The data should have been protected before the vendor's analyst ever got his/her hands on it. Oracle Database Vault would have prevented even a DBA-type user from being able to access the sensitive user data that was exposed here. These are not new technologies; they’ve been around for many years with plentiful documentation and industry awareness.

Unfortunately, a few of the early comments I read on this particular event were declarations or warnings about how this proves that cloud is less secure than on-premises deployments. I don’t agree. Many cloud services are configured with security by default and offer far more protection than company-owned data centers. Companies should seek cloud services that enable security by default and that offer layered security controls; more security than their own data centers. It’s more than selecting the right Cloud Service Provider. You also need to choose the right service; one that matches the specific needs (including security needs) of your current project. The top CSPs offer multiple IaaS and/or PaaS options that may meet the basic project requirements. While cloud computing grew popular because it’s easy and low cost, ease-of-use and cost are not always the most important factors when choosing the right cloud service. When sensitive data is involved, security needs to be weighed heavily when making service decisions.

I'll leave you with this. Today's computing landscape is extremely complex and constantly changing. But security controls are evolving to address what has been called the extended enterprise (which includes cloud computing and user mobility among other characteristics). Don't leave security in the hands of humans. And apply security in layers to cover as many potential attack vectors as possible. Enable security by default and apply automated checks to ensure that security configuration guidelines are being followed.

Note: Some of the content above is based on my understanding of Oracle security products (encryption, masking, CASB, etc.) Specific techniques or advantages mentioned may not apply to other vendors’ similar solutions.

Deep Data Governance

One of the first things to catch my eye this week at RSA was a press release by STEALTHbits on their latest Data Governance release. They're a long time player in DG and as a former employee, I know them fairly well. And where they're taking DG is pretty interesting.

The company has recently merged its enterprise Data (files/folders) Access Governance technology with its DLP-like ability to locate sensitive information. The combined solution enables you to locate servers, identify file shares, assess share and folder permissions, lock down access, review file content to identify sensitive information, monitor activity to look for suspicious activity, and provide an audit trail of access to high-risk content.

The STEALTHbits solution is pragmatic because you can tune where it looks, how deep it crawls, where you want content scanning, where you want monitoring, etc. I believe the solution is unique in the market and a number of IAM vendors agree having chosen STEALTHbits as a partner of choice for gathering Data Governance information into their Enterprise Access Governance solutions.

Learn more at the STEALTHbits website.

IAM for the Third Platform

As more people are using the phrase "third platform", I'll assume it needs no introduction or explanation. The mobile workforce has been mobile for a few years now. And most organizations have moved critical services to cloud-based offerings. It's not a prediction, it's here.

The two big components of the third platform are mobile and cloud. I'll talk about both.

Mobile

A few months back, I posed the question "Is MAM Identity and Access Management's next big thing?" and since I did, it's become clear to me that the answer is a resounding YES!

Today, I came across a blog entry explaining why Android devices are a security nightmare for companies. The pain is easy to see. OS Updates and Security Patches are slow to arrive and user behavior is, well... questionable. So organizations should be concerned about how their data and applications are being accessed across this sea of devices and applications. As we know, locking down the data is not an option. In the extended enterprise, people need access to data from wherever they are on whatever device they're using. So, the challenge is to control the flow of information and restrict it to proper use.

So, here's a question: is MDM the right approach to controlling access for mobile users? Do you really want to stand up a new technology silo that manages end-user devices? Is that even practical? I think certain technologies live a short life because they quickly get passed over by something new and better (think electric typewriters). MDM is one of those. Although it's still fairly new and good at what it does, I would make the claim that MDM is antiquated technology. In a BYOD world, people don't want to turn control of their devices over to their employers. The age of enterprises controlling devices went out the window with Blackberry's market share.

Containerization is where it's at. With App Containerization, organizations create a secure virtual workspace on mobile devices that enables corporate-approved apps to access, use, edit, and share corporate data while protecting that data from escape to unapproved apps, personal email, OS malware, and other on-device leakage points. For enterprise use-case scenarios, this just makes more sense than MDM. And many of the top MDM vendors have validated the approach by announcing MAM offerings. Still, these solutions maintain a technology silo specific to remote access which doesn't make much sense to me.

As an alternate approach, let's build MAM capabilities directly into the existing Access Management platform. Access Management for the third platform must accommodate for mobile device use-cases. There's no reason to have to manage mobile device access differently than desktop access. It's the same applications, the same data, and the same business policies. User provisioning workflows should accommodate for provisioning mobile apps and data rights just like they've been extended to provision Privileged Account rights. You don't want or need separate silos.

Cloud

The same can be said, for cloud-hosted apps. Cloud apps are simply part of the extended enterprise and should also be managed via the enterprise Access Management platform.

There's been a lot of buzz in the IAM industry about managing access (and providing SSO) to cloud services. There have even been a number of niche vendors pop-up that provide that as their primary value proposition. But, the core technologies for these stand-alone solutions is nothing new. In most cases, it's basic federation. In some cases, it's ESSO-style form-fill. But there's no magic to delivering SSO to SaaS apps. In fact, it's typically easier than SSO to enterprise apps because SaaS infrastructures are newer and support newer standards and protocols (SAML, REST, etc.)

My Point

I guess if I had to boil this down, I'm really just trying to dispel the myths about mobile and cloud solutions. When you get past the marketing jargon, we're still talking about Access Management and Identity Governance. Some of the new technologies are pretty cool (containerization solves some interesting, complex problems related to BYOD). But in the end, I'd want to manage enterprise access in one place with one platform. One Identity, One Platform. I wouldn't stand up a IDaaS solution just to have SSO to cloud apps. And I wouldn't want to introduce an MDM vendor to control access from mobile devices.

The third platform simply extends the enterprise beyond the firewall. The concept isn't new and the technologies are mostly the same. As more and newer services adopt common protocols, it gets even easier to support increasingly complex use-cases. An API Gateway, for example, allows a mobile app to access legacy mainframe data over REST protocols. And modern Web Access Management (WAM) solutions perform device fingerprinting to increase assurance and reduce risk while delivering an SSO experience. Mobile Security SDKs enable organizations to build their own apps with native security that's integrated with the enterprise WAM solution (this is especially valuable for consumer-facing apps).

And all of this should be delivered on a single platform for Enterprise Access Management. That's third-platform IAM.

Virtual Directory as Database Security

I've written plenty of posts about the various use-cases for virtual directory technology over the years. But, I came across another today that I thought was pretty interesting.

Think about enterprise security from the viewpoint of the CISO. There are numerous layers of overlapping security technologies that work together to reduce risk to a point that's comfortable. Network security, endpoint security, identity management, encryption, DLP, SIEM, etc. But even when these solutions are implemented according to plan, I still see two common gaps that need to be taken more seriously.

One is control over unstructured data (file systems, SharePoint, etc.). The other is back door access to application databases. There is a ton of sensitive information exposed through those two avenues that aren't protected by the likes of SIEM solutions or IAM suites. Even DLP solutions tend to focus on perimeter defense rather than who has access. STEALTHbits has solutions to fill the gaps for unstructured data and for Microsoft SQL Server so I spend a fair amount of time talking to CISOs and their teams about these issues.

While reading through some IAM industry materials today, I found an interesting write-up on how Oracle is using its virtual directory technology to solve the problem for Oracle database customers. Oracle's IAM suite leverages Oracle Virtual Directory (OVD) as an integration point with an Oracle database feature called Enterprise User Security (EUS). EUS enables database access management through an enterprise LDAP directory (as opposed to managing a spaghetti mapping of users to database accounts and the associated permissions.)

By placing OVD in front of EUS, you get instant LDAP-style management (and IAM integration) without a long, complicated migration process. Pretty compelling use-case. If you can't control direct database permissions, your application-side access controls seem less important. Essentially, you've locked the front door but left the back window wide open. Something to think about.

Game-Changing Sensitive Data Discovery

I've tried not to let my blog become a place where I push products made by my employer. It just doesn't feel right and I'd probably lose some portion of my audience. But I'm making an exception today because I think we have something really compelling to offer. Would you believe me if I said we have game-changing DLP data discovery?

How about a data discovery solution that costs zero to install? No infrastructure and no licensing. How about a solution that you can point at specific locations and choose specific criteria to look for? And get results back in minutes. How about a solution that profiles file shares according to risk so you can target your scans according to need. And if you find sensitive content, you can choose to unlock the details by using credits which are bundle-priced.

Game Changing. Not because it's the first or only solution that can find sensitive data (credit card info, national ID numbers, health information, financial docs, etc.) but because it's so accessible. Because you can find those answers minutes after downloading. And you can get a sense for your problem before you pay a dime. There's even free credits to let you test the waters for a while.

But don't take our word for it. Here are a few of my favorite quotes from early adopters: 

“You seem to have some pretty smart people there, because this stuff really works like magic!”

"StealthSEEK is a million times better than [competitor]."

"We're scanning a million files per day with no noticeable performance impacts."

"I love this thing."

StealthSEEK has already found numerous examples of system credentials, health information, financial docs, and other sensitive information that weren't known about.

If I've piqued your interest, give StealthSEEK a chance to find sensitive data in your environment. I'd love to hear what you think. If you can give me an interesting use-case, I can probably smuggle you a few extra free credits. Let me know.

Data Protection ROI

I came across a couple of interesting articles today related to ROI around data protection. I recently wrote a whitepaper for STEALTHbits on the Cost Justification of Data Access Governance. It's often top of mind for security practitioners who know they need help but have trouble justifying the acquisition and implementation costs of related solutions. Here's today's links:

KuppingerCole -
The value of information – the reason for information security

Verizon Business Security -
Ask the Data: Do “hacktivists” do it differently?

Visit the STEALTHbits site for information on Access Governance related to unstructured data and to track down the paper on cost justification.

Data Growth is Bringing Security and Ops Together

There was an interesting article posted last month in NetworkWorld by Jeff Vance applying the concept of hoarding to electronic data. My favorite quote (altered slightly) from the article is borrowed from Yogi Berra:

Nobody goes there anymore. It's too crowded.

Vance was talking about SharePoint. To paraphrase one point: as SharePoint becomes the de facto content management system for an organization, it's performance is impacted by data growth and increased usage. Vance also points out that firms like IDC and Gartner are predicting huge growth in the amount of data being stored by enterprises. And while storage costs have decreased (and may even be an enabler), data center space and management costs increase as data grows.

There's more in the article like the impact on search, legal fees, and HVAC costs but I'm sure you get the idea (and you could always go read the article yourself).

So, why do I bring this up? Lately I've been forced to think about the negative impact of data growth by the customers I'm speaking with about their unstructured data. Many are concerned with security, but operational concerns are also prevalent. Some ONLY care about the operational concerns. Since we have a scanner that can report on data and usage, it should also provide reports on unused content and disk utilization. Right? Well, I'm certainly not going to disagree with solving real-world business problems.

I find myself speaking two languages in the same product discussion: security and operations. And as data grows across SharePoint and File Systems, I expect to see more of the same. With audit as a third big driver, maybe I can coin an acronym here - SOA. It's never been used, has it?

BTW, We have a solution that's really good at scanning large scale unstructured data environments and performing endless analysis on the data to answer all sorts of questions. We're working with a few other vendors in the IAM/IAG space who see value in that capability and may have holes in their portfolios around unstructured data. So far, those partnerships have been driven mostly by security and audit. But since the customer organizations are also driven by operational concerns, we're also talking to storage platform vendors. If you have similar interest, let me know.

Rule-Based Log Correlation: An Alternative Approach

In an article at SYSCON Media, Gorka Sadowski writes about SIEM technologies and specifically about the complexity of event correlation.

Why Rule-Based Log Correlation Is Almost a Good Idea: The Future of SIEM

He points out that there are some challenges with static rule-based correlation. But, he calls it "the engine for the first generation of [SIEM]". That sounds about right. What scares me is that the future solutions to which Sadowski alludes look even more complicated. So, there may be a trade off to get the perceived increase in value.

I have an alternative solution that simplifies things for the SIEM. Over the past few years at NetVision, we've had a number of organizations interested in the NVMonitor solution (now called StealthINTERCEPT) because of its advanced filtering and from-the-source event collection. It doesn't rely on logs and enables a highly advanced ability to filter events as they happen eliminating the need for after-the-fact correlation.

For example, when looking at Active Directory Security Group events, you can return only changes to high-risk groups or changes to business-line groups that are not made by a specified subset of users (even if they may be a domain administrator). These events are pre-filtered and sent to the SIEM only when appropriate. It can also block events, btw, and send the event to the SIEM as an "attempt" rather than an actual event. And of course, it has it's own alerting and response mechanisms built in for real-time, contextual response.

Improved data collection on key source systems may be a better alternative to mathematic modeling from the event archive. Perhaps not in every case, but on core security infrastructure like Active Directory where rules are definable and today's challenge lies in the ability to implement, it's not only better, it's here today and already proven in production environments.

Finding & Closing Open File Shares

My team has been working on an advanced workflow for finding and closing down open file shares. I think we've really nailed it. At a few customer environments, we've scanned thousands of servers, performed the analysis to discover and prioritize high-risk file shares, and have the complete workflow to tighten the controls and/or shut them down as appropriate. If you have a need in this area, shoot me a note. I'd love to walk through it with you and see if we can help.

Access Governance Continuum

I've been pretty focused recently on Access Governance and specifically how large organizations can get their arms around the problem of access as it relates to unstructured data (mostly file systems and SharePoint). Most of the people I speak to who have responsibility for answering the related tough questions are simply overwhelmed by the sheer size and complexity of the challenge.

It led me to consider that there are a different set of tasks I'd recommend to those people than I might to someone who has a somewhat more mature access governance program. So, I started documenting an Access Governance Continuum; a maturity model of sorts that discusses how to tell where you stand and what the ideal next steps might be. A whitepaper is in the works, but essentially it looks something like this:

Confused > Planning > Cleaning > Maintaining

To illustrate a few examples:

In the Confused stage, you might want to run scans to identify open file shares. In the Planning stage, you'd be identifying data owners / custodians for those shares. In the Cleaning phase, you'd be working to clean up trouble spots and diving deeper based on what you've found. And in the Maintenance stage, you'd be automating some of the cleanup based on business rules.

This is all based on real-world projects, what has worked for the world's largest organizations, and how that knowledge translates to a mid-market need for pragmatic solutions.

...more to come.

Identity Solutions and Unstructured Data

Being in the space for so long, I'm always looking for ways to provide new, interesting functionality. To date, identity (IAM) solutions have no insight into the usage of unstructured data. And it would be really cool if they did.

IAM vendors have only recently begun thinking about unstructured data at all. Some have the ability to look across file system permissions and perhaps include rights information in reports along with basic user and group data. I don't think any do a great job of including a view across file system, Sharepoint, SQL Server, and Exchange Public Folders. But regardless of platform, the capability seems to stop at reporting on rights as they exist at some point in time.

The next logical step would be to watch user activity and be able to provide recommendations and reporting on usage along with permissions. Then, you could make better decisions. Think about this: IAM gives department managers the ability to manage security groups. Maybe they know what the group should access. And maybe they have some idea of what users should be in the group. But, there's no easy way to see which members of the group have exercised those rights and actually accessed the resources in question. Or even whether those resources are actually still relevant. (Have they been accessed? By who? How does that affect the concept of 'least privilege'?)

I'd love to hear your thoughts.

BTW, this isn't purely rhetorical. But, you'll have to be patient if you want more details. ;)

How to clean up years of permission bloat

Since joining NetVision a few years ago, I've spoken to countless organizations who are faced with clean up duty. For years, administrators have granted permissions, added group memberships, created countless new security groups, delegated rights in Active Directory and have been mostly in a reactive mode. That is, they grant permissions in response to some member of the business asking for new rights. Unfortunately, business managers have not had motivation to request that permissions be revoked when appropriate. So, in many cases, there are hundreds or thousands of security groups that nobody seems to know what they're for or how they should be used. And some big percentage of the user population has access to files/folders that they shouldn't.

In an ESJ article titled Coming Clean: Getting a Handle on Permissions and Group Memberships, NetVision CEO David Rowe discusses the challenge and explains how you can regain control over network access rights.

The End of Internet Security

Remember all that stuff I said about how we already have an end-to-end security solution that ensures that users are connected to the right web site and that there's no eavesdropping going on? Well, you can scratch all that.

I knew there was a User Experience problem with SSL in that most people ignore that it's happening and therefore don't notice when it's not happening. I also knew that there are known potential attacks on SSL, but it seems there's a newly discussed renegotiation problem that makes the whole system seem suspect. This posting from RSA does a good job at providing an explanation.

This is a big deal. SSL really IS web security. So many other security solutions rely upon it -- assuming that communication is safe and secure because it's done over SSL. Even if all the major vendors get a fix out tomorrow, we'll probably see this problem around for years to come.

Crows Using Vending Machines and the Security Implications

As reported in the NY Times, researcher Josh Klein actually taught crows to buy their own food from vending machines. If you have 10 minutes, the TED presentation is definitely worth watching. Crows are way more intelligent than you would think.

And we think we can stop them with an inanimate pile of clothes stuffed with hay!


Of course, there's a lesson to be learned for information security practicioners. Your company's employees and system adminstrators will learn and adapt. They can see the scarecrow that you've put in place to ensure security. And they figure out how work around it.

Security company RSA in their Oct. 2008 survey reported that:

53% [of employees] have felt the need to work around IT security policies in order to get their work done.

Those are well-meaning employees just trying to do their best for the company.

A recent NetworkWorld article titled Inside a data leak audit provides a real-world example. It describes an organization that was seemingly doing everything right with regard to information security. But, a thorough audit revealed 11,000 potential leaks in two weeks. All the scarecrows you could imagine were hanging on posts all across the organization. They weren't enough.

Preventative security doesn't always get the job done. Many organizations would benefit from real-time audit and monitoring solutions. In addition to after-the-fact forensic and audit trail benefits, active monitoring can be a powerful deterrent and even enable real-time remediation.

USB Drive Security Issues

The SANS Institute recently published a document discussing Universal Serial Bus (USB) drives (also called Thumb Drives, Flash Drives, or USB Keys) and their implications on enterprise security. It's a good overview of the basic threats, types of attacks, as well as common risk mitigation strategies.

It's titled: USB - Ubiquitous Security Backdoor

Despite the lame title, if you're trying to make sense of the threat posed by flash memory drives, it's worth a look. Of course, if you're already a security guru, you can give this one a pass.

Online Identity Privacy - Users Don't Take Precautions

One of my tenets for online privacy is:

Don't do anything online that you absolutely want to keep private.

Case in point:

I was looking through the form submissions to my company's web site. There is consistently some percentage of submissions that are auto-submitted SPAM. Sometimes, it's obvious and sometimes not.

Today, I was researching one submission and googled her name and email. The search brought me to a page that listed a spreadsheet of form submissions to another site - complete with names, email, phone numbers, and comments. Some obvious spam, but others obviously real.

They're showing up because of a technical glitch or security issue on the site. The google search brought me directly to the site's administrative page with no logon.

What makes this story interesting is that the site is a Las Vegas escort service and some of the form submissions read as follows:

• From a student (@uwec.edu) - "very interested"
  
• From a student (@wvu.edu) - "I need a price on ____"
  
• From someone claiming to work at Microsoft - "Hi, I'm planning a trip to Vegas with my fiance but I wanna get away from her for one night. What is the limit to your services and who would you recommend? I need a girl with _____. Thank you for your time." (how polite) ...he may not have put his real company, but another quick search found his email address with a profile telling me that he lives in Seattle(!)
  
• From a Web Developer in MN - "I am interested in an escort to accompany me to dinner" - (I found his LinkedIn profile because he provided his real company name)

...you get the idea.


Two lessons:

• First, the obvious one - don't trust web sites to keep your information private.
  
• Second, (to the security practitioners who read this blog) - don't underestimate how willing people are to give up their personal information to even the most suspect organizations.

btw - Who thinks this privacy breach will be reported?