3 Seattle SecureWorld Highlights

This was my first time attending Seattle SecureWorld Expo 2014, having nothing else to compare it to besides the IT Summit, Interface, and the granddaddy RSA Conference. There is no place like home: knowing many of the people, and being in Meydenbauer Center feels really nice.

David Matthews of MK Hamilton & Associates kicked it off for me with “Divided We Fall”. His message was about developing a community of security professionals helping each other in a common cause. Who are our adversaries? Everybody. Who are we protecting? Everybody. Why should we all join together for a group hug? For our kids.

Robert Bigman of 2BSecure was our keynote speaker for Day Two. His cybersecurity presentation was about what works well. I found his historical perspective refreshing: we’ve been carrying around all this excessive weight for decades (legacy code), so it’s no wonder we feel like crap. Perhaps our beloved technology is due for a major correction – the Frankenstein we’ve created has no room left for another band-aid, belly belt or attached device.

Simon Crosby of Bromium offered a new perspective, which I liken to accepting we will die and need a strategy for dealing with failing body parts to maintain our health as long as possible.

While there are slide decks and materials available for those of us who missed it, we do have to be present at these events to capture the nuances which cause the neurons in our brains to fire and spawn new thought processes. The consolation prize goes to those who follow the forensic trail of info-nuggets toward the next goal on our quest.

And who was it who said, “The Russians and Chinese have that network diagram Bob’s been promising us for months”? Bigman?

Never pass a problem

Recently I was asked by a cybersecurity professional, “Can you give me some examples of controls related to Information Security?”

“Proper vetting and onboarding of new employees.” I could sense the disappointment in hearing my answer, but he did not dismiss it as a trivial concern.

Even if employees are not all privileged users, they are inside the firewall and within our card-key controlled facilities. With technology so prevalent, there is hardly any separation between security and information security. Protecting the workplace is, or should be, one of our top priorities.

In this post, I address HR Compliance and how some “best practices” result in the exact opposite of what we intended. Practices resulting in:

The erosion of self-protection mechanisms
Poorly-trained staff lacking resources to execute tasks
Transfer of risk and accountability from managers to subordinates
Abuse and negligence handling sensitive employee data

I present specific scenarios, some representing “the perfect storm” of all four unintended effects listed above:

Personal observation: In a WiFi-enabled fast food place, a minimum wage worker meets his prospective supervisor to verify his I-9 documents. The supervisor takes a photo of his Driver’s License and Birth Certificate using his iPhone, emails it to himself, and submits the proper I-9 form to corporate using his laptop over public WiFi.

Personal experience: Filling out an on-line job application exceeding one hour (including a 200 question psychology assessment and background check information), culminating with an eSignature validated with job portal login, password, and SSN, which after submission, was presented in clear text when “printed for your records.”

Pre-employment drug screening: Some employers and occupations have a legitimate requirement, while others do not. This invasive practice is sometimes abused as a compensating control for lack of managerial supervision or proper vetting procedures. As a “voluntary requirement” for organizations claiming to be 100% drug-free, this can be quite discriminatory. Who gets screened may depend upon whether one is an employee or a contractor, when they were hired, etc. Often, only poorly-compensated, under-skilled employees are tested while others responsible for critical roles (like conducting information security or compliance audits) are not. What’s the risk-basis for this? Someone on anti-depression medication with a cache of semi-automatic weapons in their basement gets a free pass, while those occasionally partaking in recreational drugs do not?

Employee liability: Some employees are required to sign an affidavit stating they can be held personally liable for loss or damage to company or customer assets, accidents, breaches of information or misuse of company resources. I personally recall participating in a new hire orientation for the Department of Homeland Security. We were all handed a very thick legal document to sign, while being told, “Security begins with you”. One person spoke up, questioning how one could assume liability for security if the system itself wasn’t secure. “Are you going to give us time to read all this?” No, we have a big job to do in very little time. If you want to read it afterwards, ask us for a copy.

Which segues into my final example, HR personnel themselves: often underpaid, understaffed, often temporary contractors. Once upon a time, HR personnel helped employees understand corporate policies and procedures, resolved conflicts in the workplace, or offered services to improve their lives at work or at home. Some still do but many employers have cut way back on investing in human resources.

Is it any wonder why employees might become discontented or dismissive of compliance efforts? Doesn’t this represent a real risk to an organization’s values and mission?

We have this golden opportunity to utilize our employees as trusted custodians within the enterprise. What is the business case for jeopardizing their security in order to protect management’s compliance with its own standards?

An Army Ranger once told me, “Never pass a problem”.

Or an opportunity.

Prioritizing Security Risks

Recently, I participated in several discussion groups on Linked In about evaluating risks vs. opportunities.

Many contributors predominantly posted theoretical questions of whether positive risks (opportunities) should be considered as well as the negative risks. As a follow-up, I’m offering one specific example for when opportunities should be considered over negative risks.

OWASP, an acronym for the Open Web Application Security Project, is an information security initiative which applies to Open Source Applications to help ensure that code and applications are secure. OWASP publishes a Top Ten list of application security risks:

A1-Injection

A2-Broken Authentication and Session Management

A3-Cross-Site Scripting (XSS)

A4-Insecure Direct Object References

A5-Security Misconfiguration

A6–Sensitive Data Exposure

A7-Missing Function Level Access Control

A8-Cross-Site Request Forgery (CSRF)

A9-Using Components with Known Vulnerabilities

A10-Unvalidated Redirects and Forwards

On face value, it would make sense to prioritize addressing each risk starting with A1 and finishing with A10.

That is, unless one is also evaluating opportunities.

It could be argued that patching any one of the Top Ten vulnerabilities presents a positive opportunity to gain a competitive edge by demonstrating secure coding and configuration practices. But my “Top Two” opportunities are: A6-Sensitive Data Exposure and A9-Using Components with Known Vulnerabilities.

A6 falls in the category of data governance and data quality, which have many positive benefits including de-duplication and eliminating one of the 7 sources of waste: over-processing. The drawback is the cost of effectively managing terabytes of data in complex enterprise systems.

A9 falls in the category of source and configuration control for DevOps, which is a much more common and mature process in most IT shops. Prioritizing this risk over others has numerous benefits: it offers quality controls over product and service delivery, thereby minimizing re-work, another major contributor of wasted production. I argue that A9 represents more of a governance process, which helps facilitate the management of other risks which are higher on the Top Ten. It is less costly than managing A6, and it is more proactive, because policies can be applied in the selection of components during the development phase. Providing guidance for selecting the best available open source components is far easier and more manageable than telling developers how to guard against injection or insecure configurations.

One rule I thumb I use in determining positive risks or opportunities is this:

If we can generate a measurable ROI, it “qualifies as a candidate for positive risk”. On the other hand, if we only have a measurable cost against an immeasurable risk, it’s a harder sell to management and we are less likely to be successful in achieving our objectives.

GRC Made Simple

Complying with a multitude of complex regulations, assessing risks of non-compliance with each statute and guideline, implementing controls for every process across multiple lines of business and at every level of an organization can be overwhelming. So much so, that people from the corporate boardroom to rank-and-file line managers often dismiss GRC as nothing more believable than a pipe-dream.

To simplify GRC:
#1. The atomic process for each instance of GRC is no more complicated than a simple Plan-Do-Check-Act (PDCA) exercise, championed by Dr. Deming. In the GRC programs we develop at metriQuality, I employ an even simpler model:
Goal-Question-Metric (GQM).
You can think of it as:
Goal = Governance
Question = Risk or Opportunity
Metric = Compliance

Or if you find this more helpful, for each application of the GRC process:
1. What is our goal?
2. How will we achieve our goal? / How will we manage risks of not achieving our goal?
3. Which metrics will we agree upon as meaningful and measurable in monitoring progress toward our goal?

Our premise for simplifying GRC is that one universal technique can be applied repeatedly to extremely complex regulations, risk, and management controls on any scale or in any context. The inspiration for this blog posting comes from the following sources I would like to attribute credit:
1) Michael Rasmussen, who quoted Albert Einstein (the Father of Simplicity) in GRC 20/20’s 2014 GRC Technology Innovation Awards post;
2) Dr. Deming, who invented or popularized the PDCA cycle;
3) Lance Hayden, the author of “IT Security Metrics”, who originally turned me on to the GQM paradigm;
4) Everyone I’ve spoken to who thinks GRC is way too complicated.

Missing sales opportunities? Audit your salesforce

Audit your salespeople? Are you crazy?
No. There are all types of audits. Performance auditing is one such useful tool.
The first time I was engaged to audit salespeople was back in the 1980’s when an insurance company wanted answers to the following questions:
Are our salespeople cherry-picking leads?
What are they telling potential customers?
How do they close sales?
Why do some sales representatives have greater rates of bad debts or cancellations?

Our mission at metriQuality is: enabling staff and protecting customers. How does a performance audit serve these goals?
For most companies, customers are their Number One concern. Employees are a close second priority. It makes sense to find out if your sales process is effective and efficient. Having an optimized sales process enables employees – from the front lines of your sales force, to those who fulfill orders, service customers, and collect payment on invoices. Delivering a message consistent with your brand is an important consideration for each customer interaction.

Partnering with other companies – also known as outsourcing – is a very strategic aspect of delivering value to customers. When we evaluate potential partners for our own firm, metriQuality, the first test is evaluating their sales process. Do they respond quickly and appropriately to sales inquiries? Sadly, a very sizable portion of all partners we consider do not pass this simple test.
What’s your score? Are your people enthusiastic about having a live conversation and listening to what your customers want? If so, where does this valuable marketing information go?

Another engagement I had in the 1990’s was serving an investment fund. The CEO was keen to find out which funds competing stock brokers were recommending and why, so I did a little “mystery shopping” – posing as an individual with 3 million dollars to invest. The CEO got the information he was looking for, but instead of stopping there, he said, “Let’s do the same exercise, and this time, let’s contact the same brokerage firms but tell them you’re only interested in investing 500k.”
What we discovered was a dramatic decrease in not only the response rate, but also in the caliber of staff who responded and subsequently, the quality of investment advice. Naturally, this came as no surprise, but because a significant portion of my client’s business came from smaller investors, the CEO turned his sights on his own firm. The resulting outcome was discovering that his own sales force fared no better than that of his competitors – in fact some even recommended competing funds and brokerage firms! Rather than confront his own employees, he took prudent steps to emphasize which client profiles contributed most significantly to their revenue streams, as well as additional measures for vetting and training new employees.

I hope this blog post helps to illustrate how “auditing your sales force” enables employees. As for protecting customers, that subject deserves a post unto its own, but I’ll offer a teaser:
Each potential customer in this case, gave sensitive personal information to individual investment advisors and received recommendations which carried a risk of harming the client’s financial position.
Enable your staff by minimizing their exposure to making career-ending blunders. This will protect your employees and protect your customers.

RSA 2014 Conference – Day Three

This is the “morning-after” blog I committed to while attending the RSA 2014 Conference, to fill in gaps between live tweets and to share a compelling, common theme distilled from engaging with scores of people throughout the day and night.
On Monday, instead of attending the opening of the RSA conference at Moscone Center in San Francisco, I attended the “political, non-commercial alternative” security conference called BSidesSF.
Comparing @BsideSF and @RSAConference is night and day.
One company, Tenable Network Security, was a main sponsor of BSidesSF, and also an exhibitor at RSA 2014. I enjoyed seeing the dichotomy of their two faces: the anti-establishment counter-culture face of predominantly pen testers, and the corporate face of the same people but predominantly comprised of business managers and sales professionals.
Seeing a demo of Tenable’s security tools, I asked one of my qualifying questions: “what is the smallest size of company that actually buys your product?” 15-20 people. “So is this something a small business can afford?” It’s $1500.00. No restrictions on number of users, licenses, nodes – just one price for everyone regardless of company size.
Contrast this pricing model with some vendors who seem to size up companies before determining a price. If you’re a small company, and want some idea of how much money it costs just to get into the game, you might be spending a lot of time filling out sales contact forms or answering pre-sales questions even before talking to someone. Business is business and money talks. When I asked a CEO of one GRC software vendor about whether third-party vendors could trust their secure portal with sensitive compliance information, he responded, “If they want to do business with you, they have to go along with it, so that is a non-issue.” He was not the only person with this point-of-view, and while I can understand the reality, I do question the attitude. I’m thankful for our counter-culture friends who champion the democratization of information security so we don’t end up with a monopoly of experts who limit access to the tools and knowledge we all need to make our environment secure.
Some industry leaders do get this idea. I had a different conversation about how can we help companies who are often the weakest link in the business ecosystem with @YoDelmar at MetricStream who said, “It’s not always about being too big to fail, sometimes it’s about being too small to fail”.

metriqualityblog

IT Governance, Risk, Compliance & Security Integration