Okay, so for the noobs, what’s GDPR? The General Data Protection Regulation, or the EU Privacy Laws on steroids. Effectively, it states that EU nationals have the right to govern their own data, wherever it resides. If you’re not an EU company but have data on EU citizens, the EU can make your life difficult if you don’t follow their rules. And if you have EU partners, they’re going to want you to not make their lives difficult. Just like non-US companies often follow PCI and SOX.

So what does GDPR require? First off, basic data protection. Encryption. SoD policies. A breach notification policy.

You may have to appoint (in only certain cases, but just do it anyway) a Data Protection Officer, or DPO, whose primary function is to make sure that anybody processing data on EU folks is compliant. It’s not an ironclad requirement for everybody, but make somebody accountable regardless. It’s a gold practice. If no one person owns compliance, it won’t get done.

Next, you have to let your EU users (or data subjects) decide how their data gets handled. You have to capture their consent to hold and/or process their data. They have the right to review it, rectify it as needed, fill in missing data elements for accuracy, request a copy of it (like in a PDF), and, where appropriate, request that the data be deleted. In fact, if they decide to withdraw their consent, you’re supposed to automatically delete it.

Encryption? That’s relatively easy. There are generic solutions for that, and then very database-vendor-specific ones. For example, the vast bulk of enterprise data is held in Oracle. Encryption’s already built it, you just have to pay for it so they’ll turn it on. Then you drag the necessary tables into the encrypted space. And so on. That’s commodity stuff.

The tough part is three-fold. First, you have to LOCATE the relevant data. Which of your attributes or columns or whatever are GDPR-related? Data is anything personal, including social media data, genetic material, the usual names and numbers and addresses, etc. Data on dependents as well, if you’re tracking people’s children.

Second, you have to consolidate that data into a centralized view or views. Make it available to the data subjects for their review and rectification. That isn’t trivial. How do you centralize handfuls of data elements from multiple directories, databases, and application stores? I’ve worked with companies that have literally hundreds of these legacy repositories.

Then you have to provide some kind of interface, so that data subjects can actually interact with this stuff. Citizens don’t care that you have split their PII over Active Directory, Radiant Logic, SAP, Oracle, etc. They just want to go to one place and see All Their Stuff.

So let’s add one more consideration: automation. Nobody knows how many data subjects are going to storm the ramparts, demanding governance over their information. Since compliance hasn’t kicked in yet, there are no case studies on what to expect. Will ten percent of my users be crazy privacy addicts? Two percent? Thirty? I suppose it depends on the kind of enterprise you are. But even if it’s only 100 people the first week, you’re not going to be able to keep up with the load. “Fix my data, send me my data, delete my data.” It will get ugly quickly if you’re doing all this manually.

Wait, wait, wait. Let’s make this even more complicated. You may have my data, but that doesn’t mean I have login credentials with you. I may have been a one-time customer but I never actually registered. So NOW I have to self-register, AND I have to identity-proof. My name’s John Smith. I’m not that other John Smith, I’m this John Smith. I provide enough data points that you can verify it’s me and allow me to claim which data belongs to me, this John Smith. Yeah, this is fun stuff. I cannot stress how non-trivial this point is, right here.

The right to be forgotten, as they call it, is another weird one. If it’s eligible data, and deletion is requested, it’s supposed to apply even to backups. Good luck with that one. And of course there are plenty of exceptions to that, since you don’t want subjects to create a financial trail and then ask for it to be wiped, maybe to cover up their money-laundering.

Don’t say, “This looks so scary, I don’t know where to start,” and then paralyze yourself with inaction. I’ve already seen it. Hiding won’t make it go away. If you’re not going to be compliant by May, consider these points:

-          You’ll be in good company

-          You’ll need to show at least a best effort

Nobody will be compliant on Day One. But don’t be that guy that is way behind the rest. Show the auditors that you’ve been doing SOMETHING. Demonstrate that you’ve located / classified a portion of your data. You’ve started working on providing data subject access. Choose your data stores, for example, based on size, volume of users, sensitivity of the data, risk, whatever. Prioritize, select the most likely target(s), and start the work. You’ll also learn the lessons that will make the next round easier.

And show that you have a PLAN for the rest of it. Here’s what I’ve done, and here’s what I’m going to do. If you show nothing substantive, you may be one of those unfortunate organizations that the EU makes an example of. And be certain, they will pick people who haven’t put out a minimum of effort and beat them with a stick, to get everybody else moving.

Take the first step. Start the journey. It’s not getting any shorter.

And in the early 1970’s at my school, the powers that be knocked huge entrances through the cinder block walls between classrooms. These gaping holes, large as a garage door, allowed us to change classes without going into the hallways. But the stated reason for this was “the free flow of ideas and cooperation.” I still have that in a pamphlet from back in the day.

This is of course some pretty silly hippie-dippie stuff. Free flow of ideas? Okay, when I’m in math class, I don’t need telepathy floating in from the English class next door. This is a high-level, optimistic notion not backed up by any kind of research or even common sense.

My own kids’ high school suffered from this kind of unwalled classroom. In some areas of the school, not the whole place, there were no real walls, and no ceiling, just partitions between class areas. This means just one thing: distraction. Noise. The occasional projectile arcing from next door. An inability to concentrate on a lit test while the history class next door is watching a documentary on World War II. Only now, a few years after my kids were both out of there, the authorities have decided to wall up these open spaces to end decades of stupidity.

It’s fine to encourage a free flow of idea and interaction. But when you’re the adults, you invoke a wee bit of control, or at least some guidance.

And that’s how you find the true value in a programming interface known as REST – Representational State Transfer. It’s not cutting edge tech. REST has been around a while. REST is a form of API, but it’s got some excellent aspects to it that make it perfect for more closed, simplified, easily-secured micro-transactions.

REST is terribly simple. It operates over HTTP, the language of the web. You can in fact launch a RESTful call from the address bar of your browser, if you’d like. You wouldn’t do B2B that way, but I’m making a point. So shut up.

REST interfaces are based on resources. I ask this Thing for other Things, and I get them back, assuming I’m duly authorized. REST is stateless, it’s a smash and grab. Garbage in, garbage out. No heartbeat. So no pesky network traffic. If you want to fake state, return a hyperlink to the requester that they can click and come right back in for more stuff. And because it’s resource-based, it’s very focused. Instead of broad queries, REST interfaces tend to concentrate on mini-transactions. There’s also the notion of security by obscurity. The requesting party doesn’t see the database or table or talking gnome that holds the information. They only know, they send some parameters, they get back some parameters, usually in the form of JSON, who killed the dragon and took the fleece.

REST is the common tongue of the Cloud. Everybody who’s anybody puts out a REST interface. This allows you to programmatically talk to them. Every time I do this blog, an RSS feed goes to a REST call that automatically tweets for me. Because I don’t have time to tweet. There’s always cool stuff on TV. And beer.

Another great value is not having to build a visual interface. “Here’s my REST API. You call on that, junior, and write your own damn GUI.”

I recently did a roadshow for Oracle, helping the plug their REST library for their database. Very simplistic, but actually a very good entryway for people trying to learn REST for the first time, and great for quickie data-sharing on a casual level. Oracle Rest Data Services, or ORDS. Look it up.

My employer has built robust REST APIs for a number of customers, including Oracle themselves, to expose the functions in their identity and access products, as well as their latest LDAP offering. Not only does it provide a fantastic developer’s platform, it also helps customers build interfaces that bridge the gap between on-premise and cloud, as Oracle and everybody else migrates there.

I know, MANY of you already know about REST. But after the tour I just concluded, I found that there are still an awful lot of influencers out there who have heard the word but didn’t know what it meant. With Cloud in all our futures, it’s time to get past the buzz term and onto that leading edge. 

And of course this is how you got OAuth, and that lovely little thing called account linking.

But here’s the catch. If somebody hacks your Facebook, they’ve got your life. It happened to a lawyer friend of mine. I got an email from him one morning, saying he was sending it from a library in London. The mail explained that he was vacationing in the UK and had been mugged. Lost his passport, cel phone, laptop. He needed some cash, and fast. He said, “I’m writing this with tears in my eyes.”

Instantly I knew it wasn’t him. First off, it’s an old scam. Second, he would sooner bite his own thumb off as shed tears over being mugged. This makes him a great lawyer.

I reached out to his kids and said, I think your dad’s been hacked. They said he was actually vacationing in the Carolinas, and they got in touch with him. I recommended an email blast to let all his contacts know there was a scam being perpetrated in his name, but naturally the bad guys had changed his email password. And in fact, they’d gotten into everything he had, by virtue of hacking his Facebook account. Now, Facebook didn’t get them into his bank, but it got them into his email and some other stuff, and they were able to get to his bank stuff that way. Luckily, some additional multi-factor shut them down.

What then got creepier was when they actually started trying to chat with me via Facebook, claiming to be him. I tried to go along and solicit some info from them, maybe to discern how to get in touch, and catch the lousy bastards. But they shut the conversation down quickly. Luckily, in the end, they got nothing from this, but it caused my friend a great deal of hassle cleaning up his accounts.

This is occasionally the argument against SSO. If somebody hacks that one password, they’ve got everything. To segment, sometimes orgs employ Reduced Sign On, RSO, meaning you need two or three passwords for a variety of apps, especially inside the firewall or VPN.

This is where multi-factor is indeed handy. You got the right password? Great. But it’s a strange box. Before I let you log in from that strange box, let me ask you a few other things. You can also deploy defenses that look at behavior. Edward Snowden talked a bunch of people into authenticating from his machine. Why didn’t any bells go off saying, “Why are all these people using this same freaking keyboard?”

I was asked for advice once when a friend’s daughter’s Neopets account was hacked. My first probing question was, what the hell is THAT? They explained, it’s a virtual pet world, in which you can earn points for taking care of your pet. The points allow you to buy virtual stuff for your virtual pet. So then I had to ask, why the hell would anyone want to steal virtual points?

But it was important to his daughter, therefore it was important to him. It was, in effect, her IP. You gotta safeguard stuff like that. 

Recently, Israel’s power utilities were seriously hacked. In 2015, the Ukraine’s grid was also attacked. You can only guess the source of that one. Even the screens of the admins trying to fix the situation were hacked, and their communications were taken down.

CIP specifically warns against web-enabling the SCADA systems that are used for gathering and disbursing operational data. But that one’s been roundly ignored from the beginning.

I wrote a while back about an insidious, clever, and horrifying attack against manufactures in the Midwest that relied heavily on mapping out the org charts, then spear phishing critical individuals. It wasn’t always even a matter of implanting malware, but rather using a brilliant sort of social engineering, convincing people that a malicious email was actually a friendly request for a money wire or other delivery. Although be assured, malware delivery is still a problem.

When the DoJ got his, when the Ukrainians got hit, those were the result of spearing.

In the last few months, I’ve gotten funky-looking emails from familiar people, with the usual, “You’ve gotta see this!” as the subject or body. And no other detail. And I know better than to click on those. All you have to do is hover over  those to see where those links will take you. I have often done a reply-all on those, warning everybody on the thread to steer clear.

It never fails to astound me how STUPID folks can be in clicking on these. And in a corporate environment, these can be unbelievably damaging. Spear phishing helped bring down a Canadian firm, eventually hurting their acquisition price. Spearing has a very high success rate, and sorry to say, that’s all based on sheer stupidity.

The grid is far too critical to fall prey to such weak thinking. If you’re in IT, if you’re in a critical organization, you have to be SMARTER. We already sweat EMP attacks from the sky. We don’t need the gopher attacks from the ground. 

Yeah, that’s fun. Cuz then the customer looks at you and asks, “Well, which way IS the right way?”

So do you want the poke in the eye, or the smack in the head?

So this is a common problem with a GRC tool, versus a roles/analytics tool.

GRC is something that’s often built into business apps. It determines in real time if a user is allowed to execute a particular action. It could be granular, such as clicking a button. Or a little higher up, like editing versus only viewing. Or higher yet, such as getting into a module at all.

Because GRC is typically app-specific, it has some limitations:

• ·         The policies are very particular
• ·         It’s tied to the version of the app, so upgrades can be a slight chore
• ·         It’s a silo, meaning not interoperable with other apps
• ·         It’s somewhat impervious to outside metadata or roles

On the other hand, it’s real-time. Can I do this right now? And can I do this inside this app, specifically related to buttons or transactions? It’s very powerful. However, in the past I have described GRC as a beautiful dress that one must be sewn into. It looks gorgeous, just don’t expect to change dresses too often. And by the way, that dress isn’t for every occasion.

A provisioning system, on the other hand, takes a different approach to the same problem. Can this user do that thing over there? Well, if I provision the user to that task or role, then yes, the user can. If I don’t provision the user to it, then no. But that’s in advance, right? And it may or may not be button-specific, meaning ultra-granular, unless I have access to the application entitlements, or I can provision to an pp-specific role. The enforcement is now the function of the app, and provisioning has simply provided the necessary ammo.

Provisioning can also tell you (and the end user) up front if they’re going to get it. In other words, should I bother trying to use it? I’ve been told at the time of request or approval that Permission B that I’ve asked for is in conflict with Permission A that I already have. So now I won’t wait for GRC to tell me later that I’m out of luck.

An extra benefit of the provisioning approach is the ability to perform SoD checks across applications. Because GRC is internal, it can’t do this unless heavily customized. Provisioning is external, and therefore CAN work cross-platform. Analytics can further help you import entitlements, organizational, and people data to help you build those policies across platforms/applications.

So if you need the real-time SoD checks, at the moment of attempted use, then yes, it’s GRC. Otherwise, consider the approach that tells you in advance whether or not somebody can even have the thing before they find out they can’t use it. It’s almost like calling the restaurant ahead of time to find out if they’re crowded, and saving yourself the ride if they are.

But wait, grasshopper. Two more points to make now.

First, “breach” means somebody got in and left their dirty fingerprints. Bypassed your feeble firewall. Cracked some passwords. It doesn’t necessarily mean they stole or broke anything.

Second, were you prepared when it happened? The sooner you resign yourself to the fact that you WILL get breached, the sooner you will prepare for THAT. If your entire strategy is based on keeping evil-doers out, you’re already screwed. Because you won’t keep them out. So plan for limiting, mitigating, or eliminating the potential damage.

In the olden days, defenders would retreat behind a line they knew they could defend, and they burned all the crops and villages in their wake, burned their own stuff, to give the invaders nothing to live off or hide in. I’m not saying you should burn your server, unless it’s an AS/400, but I’m saying, don’t give the invaders anything to live off or hide in.

-          If data is encrypted, it doesn’t matter if a bad guy in a mask walks off with your server on a dolly.

-          If production data is masked before it’s used in testing, it can’t be compromised.

-          If your network is segmented, you’re possibly allowing for some damage, but not total destruction.

-          If you implement segregation of duties, especially at the database level (INCLUDING service accounts), you are preventing invaders from using your own privileged accounts against you.

Here’s another point. Multiple customers have told me, they won’t get fired for a breach, because even their BOSSES know it’s going to happen. But they WILL get fired if

1)      They’re not prepared to react to a breach

2)      They fail the audit in advance of a breach

See, breaches are baked in, at least by people who know what they’re talking about. If the bad guys get in, and they get nothing useful, then you’re good.

For now.

One more important thing from the Gartner show in DC: the Gaelic steak at Harrington’s Irish Pub is freaking phenomenal. What’s that got to do with security? Nothing.

At first glance, this seems ridiculous. These guys should know this already, right? “We handle money. Bad guys like to STEAL money. So we’d better be careful.”

But if you were in the security business, you would know one inscrutable fact: way way way way way way way way too many companies are not careful at all.

“We got a firewall. We’re good.”

“”We make people change their passwords once a year, we’re good.”

“Our accounting audit people look at our IT controls annually. We’re good.”

But ohhhhhh, it gets worse. In the last year, I’ve seen:

• ·         Companies that have literally NEVER required a password change
• ·         A company whose guest wifi password was ridiculous easy to guess, and never changed
• ·         Companies with dozens of applications, all of which were manually provisioned (i.e. somebody punches names into a keyboard for every single app)
• ·         A company that allowed a 30-retries policy for flubbed passwords

Now, when I heard the 30-strikes-and-you’re-out policy, I said, Huh?” It was explained  to me that they had some rather unsophisticated users who knew the business, but who were not great with a keyboard. I pointed out two things to change their minds:

1)      30 strikes gives brute-force attacks a FAR higher chance of succeeding

2)      If someone is so ill-coordinated that he could fat-finger that much, OR that he couldn’t remember a 6-to-8 character password, that person is too dumb to work for the firm

Many vendors (software or otherwise) segment their customers in various ways. One way is by vertical, so that you have subject matter experts selling into pharma, or power grid, or federal government. The other is by size. Enterprise accounts are massive targets, while local or national accounts are smaller.  Larger accounts tend to already have an identity and access framework. In fact, many are on a second or third. Smaller ones chronically have little to nothing. It always astounds me at the complete lack of automation. It’s not even the number of users that matters. It can be the complexity. Compliance requirements. Difficult audits. Security worries. The number of resources.

There’s no excuse any more. If you get nailed for lack of effort, you deserve it. Sorry, but you’re a goon. There are too many threats, and too many targets.

Don’t think that you’re too obscure to get hit. If you manufacture the eyeballs that go on kewpie dolls that a rube might win after nineteen rounds of Skee Ball at the carnival, but you have an accounting system that dispenses money, you are on somebody’s hit list. I deal with a lot of vertical industries, and even I occasionally run into a client  I’d never heard of before.  I remember the first time I went into Worldcom, when they were nobody, long before they exploded and imploded,, and I had to explain to my boss later who they were and why they were a customer worthy of a visit.

Don’t be one of those many organizations I visit who are just begging for crap to happen. Protect your users. Protect your data. Start with the data, if you’ve done nothing else. And don’t think a firewall is the answer to anything beyond the basics.  Be smarter than that.

It’s always fun to watch the headlines, and hear about the latest corporate hacking disaster. Part of the fun is hearing the so-called experts give the 10,000-foot explanation of what they think happened, and often these are people who know the buzzwords but don’t actually know that they mean. We’ve all heard some ridiculous post-mortems from dummies who are good for talking to pundits but who risk all credibility if they’re dumb enough to actually talk to any white-hat types and get picked apart.

Yes, we still have to worry about those generic “hackers,” those mysterious types who do whatever keyboarding evil they do who “break in” and steal data. TV types can’t comprehend OWASP or SANS or common exploits. You’ll never hear the  term “SQL injection” on CNN.

But as brilliant as some of these bad guys are, they STILL quite often rely on bad practices, social engineering, and just plain stupidity. However, they can be sophisticated enough to leverage people’s personal connections.

Let’s pull this apart. Let’s compare a social attack to SQL injection. It’s an iterative attack, i.e. it’s not a smash and grab. Find the databases, find the tables, examine the schema, then go after the data.

Recently I’ve spoken to organizations who describe multi-layered, extremely clever attacks that require several passes, and are still just social engineering, but to such a degree that it’s far beyond conning a secretary over the phone into handing out a password.

Example 1: purchasing agent gets an email, containing an attachment requesting a wire transfer, from a manufacturing manager. “Need this much cash to buy these mundane raw materials to build this boring product.” The required form is properly filled out, appears to be pre-approved by yet another party, and the proposed transaction is in line with other transactions they process several times a day. The purchasing agent has a question about the form, emails back, and gets an appropriate response so he also approves, and sends the wire transfer request along.

Then there’s an issue with the account number, and it bounces back. The purchasing agent finally says, screw it, I’ll make a phone call to the manufacturing manager, who then says, “What wire transfer are you talking about?”

The bad guys hadn’t hacked a bank account or explicitly moved money. They had infiltrated email, mapped out the organization, who dealt with whom, how business was transacted, how money was moved, then tried to get privileged employees to do the work FOR them. After hearing this story, I heard from several other companies in the same geographic area that had been attacked in the same way.

Example 2: a technology company is on an acquisitions binge. Lots of little purchases are going on everyday as people and even furniture are getting moved around, offices are being dissolved, severances are being paid, equipment is being consolidated. The CEO is personally overseeing many of these small expenditures. The CEO goes by a nickname. One day his secretary gets an email from him asking for a transfer of cash for a merger-related activity, but using his full name. The long-time secretary is instantly suspicious because the boss didn’t use his traditional nickname in signing the email. And yep, it wasn’t him. Someone is trying to take advantage of the chaos of the M&A activity.

It’s important to have all the right tools and policies in place. All your sensitive data should be encrypted. Multi-factor authentication and authorization are phenomenal things. Segmented networks can limit damage when somebody DOES get in.

But it still pays to be smart, to be vigilant. There’s an old saying from the Middle East: trust, but verify. Well, screw trust. Just verify.

Whoa. Hang on. Connecting is easier? Absolutely. Trust is another matter.

We already have an environment in which too many people are not who they say they are on the net. I have a very good friend who says Facebook is the best authenticator in the world, since it knows so much about you. And yet a large percentage of FB accounts are bogus, or surplus. And anybody can steal your vacation or kids’ photos and claim ownership.

Mobile devices are also more easily stolen, compromised, appropriated, corrupted. And disposable. They get swiped all the time. And before they can be traced after ill use, they can be dumped.

This is why we in the security world talk about assessing and reacting to RISK. We calculate it, even after authentication. You might have the right creds, and you might even do the right things, to start a session or connection. But then you might turn out to be evil after all. A few years ago, an investigative show sold a “stolen” credit card online, then tracked its use. The bad guys who bought it bought a couple of very innocuous items to start with. Once the transactions went through without a hassle, they started buying junk. So it pays to keep an eye on a user, even after they pass the smell test.

 This is why your device should be married to YOU. It should be part of your identity. Just like your IP address, your habits, your authentication method. If somebody else uses your device, the system you’re connecting to should either think twice about letting it in, or prompt for other creds. If YOU use somebody else’s device, same deal. Airports are great places for people to listen in on, physically or in the air, somebody else’s creds, and use them for evil stuff.

So I guess you could accept Ms. Mayer’s statement IF you trust other devices. But heck, as many hackers have stated recently, the Heartbleed bug means that the Internet of Things, that is the connectivity to and from our devices, is at risk. So maybe it’s just bad timing on her part. Just don’t make it bad timing on yours. There’s a wonderful old Arab axiom on this subject. Trust, but verify.