Friday, October 13, 2017

Microsoft should take a lesson from US Admiral McRaven

For the love of all that is holy, publish timely, accurate, helpful documentation on your products and services!

I attended a "Security Seminar" at Microsoft's office yesterday, oddly, it was interesting. Lot's of sales pressure to be sure, interesting speakers (oddly), some interesting content (even more interesting), lunch was out-freaking-standing, but...the Evil Empire (my old Alma Mater, Microsoft) is suffering more and more each week with "...can't see the forest from the trees..." syndrome. In their rush to make everything "Azure Cloud Enabled" they are violating the 6"P's" of the Information Technology World, namely, their documentation sucks like a black hole!

Competent product documentation is expected for a company like yours, if you can't get the little things right, how can we trust you with the big stuff?

Learn to make your bed every morning dog gone it!

They could really take a lesson from US Navy Admiral McRaven's 2014 University of Texas commencement speech, made famous on Youtube, you are Microsoft for crying out loud, we expect you to do great things, but for the love of all that is Holy, do the little things right, but NO! Their product documentation really, really sucks, and the really sad part is that in the seminar yesterday, when I asked about this, they freely admitted it. They asked me to upload my documentation for them to plagiarize!

For the last few months, we've been working with Microsoft's new Data Loss Prevention [DLP] suite (a mix of some E3 and E5 level products) and they have very compelling capabilities, a rich Chinese Menu approach to DLP, somewhat difficult to explain to Engineering and Software Development Managers (we've got over twenty-five of them), but we've developed some cheat sheets, take the sting out of the Organizational Change Management [OCM] aspects of the adoption. The OCM aspects are by far the most difficult part of the implementation to date.

The big hurdles have been:

(1.) Finding relevant documentation.

If we could have found relevant documentation on the concepts, basic building blocks, product names (which seem to change almost daily), capabilities, etc...things would have gone so much more smoothly. I mean...really? The power of "scoped policies" in the Azure Information Protection blade, a total white wash in your documentation, a veritable King Kong powerhouse in reality.

(2.) "How To" articles that make no sense whatsoever.

You are not wanting for articles entitled, "blah, blah, blah deployment Roadmap...", if only it WAS a roadmap! Ninety-nine times out of one hundred it was just some engineers mental masturbation about how cool his dream is and how stupid you are for not sharing the dream and understanding his user experience to support his dream. An endless parade of embedded hyperlinks in the online documentation that takes you farther and farther down the rabbit hole and provides little to no value to the "roadmap" you are looking for in the first dang place!

I mean, now really, even Perry Clarke would have trouble figuring out how to enable AIP based outbound mail rules in this fine kettle of fish.

(3.) Blog articles that promise to be timely and relevant.

The best was the Information Security Blog article that talked about their fabulous new Tech Writer and his/her valiant efforts to bring things up to date and make them relevant. Nice idea, but, five months after the article, none of this has materialized. We used to joke that "...Microsoft has the worlds worst software and the worlds greatest marketing!...". It is no less true in 2017 that Microsoft still has the worlds best marketing (lord knows I got a refresher bombardment of marketing yesterday) and now they have the worlds worst product documentation.

Proud Moments to be certain.


Guys, take a breather like you did with your " computing..." initiative and bring in a small army of Tech Writers, and make your Product Marketing Managers and Engineers work with them to provide we, your customers [you know, those annoying people that pay you?], with documentation worthy of the name "Microsoft", not shiny, not flashy, not "gameificationed" just helpful.

But you wont...

So, Microsoft guys and gals, if your still reading, go read this book, we, your frustrated and very technical customers will be glad you did:

Admiral McRaven's book on Amazon

Thursday, October 5, 2017


Just to prove that I am NOT the only person with great ideas, this gem is from Jeff Haden over at INC Magazine (online). It certainly resonates to those of us that worked for tyrannical managers (don't refer to managers as Leaders typically).

Many people are good bosses. Some people are great bosses.

A handful go even further: They're phenomenal, not only because of what you see them do but also because of what you don't see them do.

If you're a truly phenomenal boss, what your employees see is far from everything they get.

1. You look past the action to understand the motivation.

Sometimes an employee makes a mistake or does the wrong thing. Sometimes an employee takes over a project or a role without approval or justification. Sometimes an employee jockeys for position, plays political games, or ignores company objectives in pursuit of a personal agenda.

When that happens, it's easy to assume that person won't listen or doesn't care. But there is almost always a deeper reason: The individual feels stifled, feels they have no control, feels marginalized or frustrated--or maybe is just trying to find a sense of meaning in their work that pay rates and titles can never provide.

Effective bosses deal with actions. Great boss search for the underlying issues that, when overcome, lead to a much bigger change for the better.

2. You forgive...and more importantly, you forget.

When an employee makes a mistake--especially a major mistake--it's easy to forever view that employee through the perspective of that mistake.

I know. I've done it.

But one mistake, or one weakness, is just one part of the whole person.

Great bosses are able to step back, set aside a mistake, and think about the whole employee.

If you're a great boss, you can also forget that mistake because you know that viewing any employee through the lens of one incident may forever impact how you treat that employee. (And you know the employee will be able to tell.)

To forgive may be divine, but to forget can be even more divine.

3. You place importance on employee goals as much as on organizational goals.

Good bosses inspire their employees to achieve company goals.

The best bosses make their employees feel that what they do will benefit them as much as it does the company. After all, for whom will you work harder: a company or yourself?

Whether they get professional development, an opportunity to grow, a chance to shine, or a chance to flex their favorite business muscles, employees who feel a sense of personal purpose almost always outperform employees who feel a sense of company purpose.

And they have a lot more fun doing it.

If you're a great boss, you know your employees well enough to tap the personal, not just the professional.

4. You support without seeking credit. This is MASSIVE!

A client gets upset. A supplier feels shortchanged. A colleague gets frustrated. Whatever the issue, good bosses support their employees. They know that to do otherwise undermines the employee's credibility and possibly authority.

Afterward, most bosses will say to the employee, "Listen, I took up for you, but...."

If you're a great boss, you don't say anything afterwards. You feel that supporting your employees--even if that shines a negative spotlight on you--is the right thing to do, and is therefore unexceptional.

Even though we all know it isn't.

5. You make fewer public decisions.

When a decision needs to be made, most of the time the best person to make that decision isn't the boss. Most of the time, the best person is the employee closest to the issue.

Decisiveness is a quality of a good boss. Great bosses are decisive too, but often in a different way: They decide they aren't the right person to make a decision, and then decide who is the right person.

You do it not because you want to avoid making certain decisions, but because you know you shouldn't make certain decisions.

6. You don't see control as a reward.

Many people desperately want to be the boss so they can finally call the shots.

As a great boss, you don't care about control. So your employees don't see you as someone who exercises control.

And that's great, because you would rather be seen as a person who helps.

7. You let your employees learn their own lessons.

It's easy for a boss to get heavy-handed and turn a teachable moment into a lesson learned.

It's a lot harder to let people learn their own lessons, even though the lessons we learn on our own are the lessons we remember forever.

Great bosses don't scold or dictate; they work together with an employee to figure out what happened and what to do to correct the mistake. They help find a better way, not a disciplinary way.

After all, great employees don't need to be scolded or reprimanded. They know what they did wrong. That's why you know that sometimes staying silent is the best way to ensure they remember.

8. You let your employees have the ideas.

Years ago, I worked in manufacturing and my boss sent me to help move the production control offices. It was basically manual labor, but for two days it put me in a position to watch and hear and learn a lot about how the plant's production flow was controlled.

I found it fascinating, and later, I asked my boss if I could be trained to fill in as a production clerk. Those two days sparked a lifelong interest in productivity and process improvement.

Later he admitted he had a larger motive. "I knew you'd go in there with your eyes wide open," he said, "and once you got a little taste, I knew you'd love it."

If you're a great boss, you see the potential in your employees--and you find ways to let them have the ideas, even though the outcome was what you hoped for all along.

9. You always go home feeling you could have done a little better.

Leadership is like a smorgasbord of insecurity. You name it, bosses worry about it.

That's why the best leaders go home every day feeling they could have done things a little better, or faster, or smarter. They wish they had treated employees with a little more sensitivity or empathy.

Most importantly, they go home feeling they could have done more to fulfill the trust their employees place in them.

And that's why, although other people can't see it, when you walk in the door every day, you make a silent commitment to do your job even better than you did yesterday.

Why? Because you're a great boss

I agree with most of this, that being said, I'd like to tip my hat to some great bosses and employee decision makers that I have known:

Ron Glickman - a visionary CIO if there ever was one.

Jeff Hekmati - a great INFOSEC skillset, coupled with humility, the heart of a servant, a rapier like wit and an Einstein like intellect

Tomas Byrnes - light years ahead of the pack, a great friend, a great father, a Modern Tesla intellect

The list goes on...

Saturday, September 30, 2017

Succeeding In Spite Of Yourself - Part One

Ever feel like a fish in a blender?

And so it begins...the story at long last can be told.

Your humble host will now tell the sordid tale of his last twenty-one months in the fast paced, no holds barred world of "C" Level INFOSEC Consulting in the Power Industry.

It all began in March of 2015. My current employer at the time, (I'd been there for four years, gone thru three CIO's and successfully built their global INFOSEC organizations) their IT Division was imploding, the Baltic Dry Index was plummeting, they were hemorrhaging cash, they were restructuring and looking to become an acquisition target for their competitors. It was time to face facts, start lining up jobs for my key team members and pull my chute's rip cord.

I met with a nice, boutique consulting firm (let's call them PNW Consulting) in the Pacific Northwest who had a long term customer with a big problem, lots of cash and a short timeline. Their customer's NERC-CIP external audit drop dead date was thirteen months away and they were having serious second thoughts about their current consulting partner delivering the goods.

They (the power company) had another boutique consulting company on site for the last eighteen months and these folks (billing out at almost $300.00/hr) had yet to do much more than fly all over the US & Canada performing discovery and antagonizing the IT Department so egregiously that the relationship had become adversarialy toxic that employees were calling sick on days with meetings with these consultants almost 100% of the time.

So, after several meetings with my new employers, their Customer Relationship Manager and I flew to the home office of XYZ Power. It was a Friday in April, beautiful weather, sunny skies, a nice ride from the airport to the XYZ Power Company Campus and Control Center. We were quietly taken to the CEO's office where we met with the CIO, VP of Legal, several members of the Board of Directors and their young CEO. The CEO, the Chairman of the Board and I instantly hit it off like we were life long friends. The other consulting company (I'll call them ATH Consulting [Atilla the Hun]) was not in attendance.

After several hours of detailed discussions (like two dogs on the street, butt sniffing), the CEO asked me, " can you start...?". "...when would you like me to start....". He asked me to start the next Monday, so I slid the contract across his desk to him and he signed it? "...don't you want to know how much this is going to cost you...?". "...I don't care, I need to be NERC-CIP compliant by April of next year. You are now in charge, you will report to me alone, you can have anything you need. If anyone gets in your way, just let me know and I'll make the problem go away...".

Well OK then! Needless to say the CIO and VP of Legal (the appointed NERC-CIP Senior Manager) did not look in the least bit happy. Welcome aboard contractor scum!

W O W ! ! ! !

So, the Customer Relationship Manager from PNW Consulting and I headed back to my home town. On the plane I asked him, "...don't you think you should put me on the payroll...?". PNW Consulting's negotiating position was at this time, tenuous at best. In hindsight, I'd have been better served to contract directly with XYZ Power, but, as they say, that is another story entirely.

Next up? The fateful meeting the next Monday.

Friday, September 29, 2017


Live Free or Die Hard, or, why do "Consulting Companies" promote slavery?

Talent acquisition is a key success factor to any business. So, why does my in house HR department and their bevy of flesh merchants have such a hard time, sorting the wheat from the chaff?

It's as if, when we talk, they are either not actually listening, or they are biding their time, waiting for their opportunity to speak.

They never seem to send candidates until I pester them, and when they do, the candidate is not an INFOSEC person, they are a shoe maker, turnip truck driver, etc...

Monday, April 30, 2012

Fear, Uncertainty & Doubt [FUD]...the Grand Illusion...or...this guy is old enough to know better...

You don't know what you don't know - or why Bruce Schneier's blog is worth reading daily -

FROM BRUCE: JCS Chairman Sows Cyberwar Fears

Army General Martin E. Dempsey, the chairman of the Joint Chiefs of Staff, said: A cyber attack could stop our society in its tracks.

Gadzooks. A scared populace is much more willing to pour money into the cyberwar arms race.


What I always want to ask folks who make these cyber-disaster claims is "How?".

What is the use case where a cyber attack has a widespread impact on the lives of Americans? I'm not talking about a cyber attack that's news-worthy, and has "society stopped" because it's watching the drama unfold on TV. I just can't follow the hypothesis that a cyber attack can be more than a massive inconvenience.

Point of calibration: last year my power was off for 5 days because a storm damaged the one-and-only electric power switching sub-station that powers my neighborhood and it wasn't easy to replace the switchgear that failed because adequate parts and skilled workers weren't available. This was a huge problem, forcing me and my neighbors to share gas generators to keep the food in our freezers cold. It cost me hundreds of dollars in food and fuel that I wouldn't normally have bought. That said, it was not an existential threat to the very tracks that society runs on in my neighborhood.

Cyber disaster needs to be more than that!

Case #1: Evil-doers find a flaw in the border gateway protocol and use it to flood the IP routing fabric with incorrect data. This could lead to no practical paths between systems on different subnets, and the end of the Internet as it currently stands.

Outcome: Using our lights, and our phones for those folks who didn't jump to VOIP, the people who make routers have to figure out and fix the problem. It's Cisco, Juniper and a handful of other folks who already know who each other is. Press the answer onto CDs and use FedEx or the Post Office to send them to all your customers. A week later, the Internet is all better, and nobody dies. When I had to live without power, I had to live without the Internet because it seems all my Internet infrastructure runs on electricity.

Case #2: Evil-doers use the Internet connected electric power infrastructure to switch off all the power in the US. I'm not even going to mention how hard this is, every electric power installation is unique, and they all use redundant sources of supply, but SCADA is a potential problem.

Outcome: Lots of angry people, more than Case #1, call to complain that the power is off (unless they went to VOIP). The electric companies unplug their routers and turn the electric power back on. It probably takes 24-48 hours, because those networked SCADA devices are labor saving. Half the impact of my storm.

Case #3: Evildoers mount a sustained, covert, untraceable (ok I'm in sci-fi here) attacks on the DNS infrastructure of the internet block all access to the root server infrastructure. Nobody can figure out what IP goes with "" .

Outcome: Write this down ( Well, what really happens is that the ISP who serves you already has a non-authoritative DNS that it uses to reduce outbound bandwidth. Those folks simply become the decentralized source of your DNS. It doesn't propagate as quickly, and so now it takes a month before some new domain name works everywhere. The Internet is less cool, and the DNS admin industry (or mafia, depending on your point of view) wants somebody's head on a platter. The rest of us are back on the internet, and maybe there is a story on page 6 when the evildoer dies in a house fire with a horse's head on his bed, to mix my mafia metaphors.

Bottom line, Where's the real disaster? It's not time for the annual April 1 contest, but we need to figure out what these generals could be talking about. If it's sci-fi, then it needs to go back to the fiction section.

WWII was an attempt to destroy society, and at least some folks thought the use of nuclear weapons was a reasonable tactic. I want to read the cyber problem for which folks think a 50TJ nuclear blast is the appropriate response. I just don't think it exists.

# # # # # # # # # #

Amen! to that!

As a retired Army Officer I can't say too much negative about General Dempsey, he is after all an Armor Officer, but really? Several Bronze Stars, with "V" for Valor? Other veteran readers hopefully will share my skepticism.


As always, when you want to separate the wheat from the chaff, ask Bruce Schneier (he's the quintessential Chuck Norris of INFOSEC):

Thursday, April 26, 2012

REAL WORLD SOA APPLICATION SECURITY -- PART TWO: Authentication (AuthN) matters, really (no...really)

When we started on our SOA ERP/CRM System Project, I was amazed by the sheer volume of hand wringing from our SOA vendor about "security".

Their flagship SOA security project was an OEM from "AmberPoint", when SUN purchased AmberPoint, well, that went out the window. So, not being dead from the neck up, I went looking for options (though my vendor assured me that, within two years, they would have a replacement product that would be amazing! Eighteen months later, I am still waiting, to be amazed that is).

In the world of SOA security, there are many players, but a few really stand out. We have a substantial investment in Oracle products, some that have been implemented well, some that have not been implemented well. To be fair, Oracle stuff, by and large works as advertised, and then some, if you can stomach the price point. From my vantage point, it was not about cost, but about risk. What would be the risk of having our authoritative source for the user object having an Oracle System of Record (SOR) and the authoritative source for authentication being an Oracle product?

Too much for my blood. Something about eggs and baskets my Mother taught me about.

We then bumped into a vendor, "Layer 7 Technologies". From a due diligence perspective, we had a side-by-side bake off: Oracle Corporate, with some excellent Systems Engineering talent; and Layer 7 Tech with their top Ninja, "Ben". Some high stakes technical guy, dog on the street butt sniffin' later, we had validated that the Layer 7 SOA Gateway would meet or exceed all our CY 2011 ~ 2013 requirements.

So, being good Corporate Citizens, we scheduled a "bake off". NOTE TO SELF: Never bring a feather duster to a knife fight.

After the bake off, during the integration proof of concept (POC) the Oracle integrator (name withheld to protect the innocent) with five weeks of prep time, could not stand up the Oracle Identity Mgmt Suite during the five day on site POC. Finally, on day five, at 6PM, the system engineer from Layer 7 walked the Oracle integrator team members thru setting up their products and they were able to connect (this did though, highlight the level of expertise that Layer 7 brought to the dance). Needless to say, I went looking for another integrator on Monday morning.

That leads me to the most stellar Identity Management Integrator team I have ever worked with, IDMWORKS, (but that is another story...).

So, our ERP/CRM application we are building is replacing a pool of ERP/CRM systems in use by companies we've purchased over the last fifteen years (one ring to rule them all!). When we purchase someone, it's about profit (as it should be) so we are slow to re-brand them (or mess with them), as long as they stay profitable. If that slips, we assimilate them in a BORG'ish fashion. So, the short version: our shiny new web user interface requires the consumer/user to enter their USERID in the form of an LDAP "UserPrincipalName" (UPN), which allows the system to differentiate an external actor in an easy manner. Our logon sequence has a few steps:

(1.) we validate the credentials from our Apache front end;

(2.) we pass these thru our Layer 7 SOA Gateway (recursive data validation and payload inspection) via SSL;

(3.) then Layer 7 hands the credentials off to Oracle Virtual Directory(OVD) over SSL;

(4.) then OVD passes the credentials to Oracle Internet Directory (OID) (this step will make integration with Oracle Financials later, easier) over SSL;

(5.) then OID uses the credentials to bind to Microsoft Active Directory, over SSL. If the bind is successful, OVD queries it's subordinate ATTRIBUTE stores for ATTRIBUTES associated with the UPN and passes this back to the web U/I which caches the ATTRIBUTE(s) and/or ENTITLEMENTS.

The web U/I can use the cached ROLE and ENTITLEMENT data, based on the relative risk rating of the business process and associated SERVICE(s) and/or OPERATION(s). The web U/I does some rudimentary ROLE to UPN, ATTRIBUTE matching before passing a request to a back end SERVICE or OPERATION, however, our Layer 7 SOA gateway protects each service and/or operation individually by validating the ROLE, UPN and/or ENTITLEMENT ATTRIBUTE data presented (as well as the source of the request), before allowing the customer/user to call the back end SERVICE or OPERATION.

This pattern is in response to several OWASP "top ten risks".

For inter-process or service to service communications we require a UML Sequence Diagram from the development team to document the communication pattern and AUTHENTICATION token requirements, before we can set up and enforce technical controls between these forms of system level communications. Our Layer 7 SOA Gateway device(s) can craft a custom token (STS) based on the WSDL of the SERVICE or OPERATION being consumed.

### More on this topic later ###


Michael Becher's excellent and timely reference on Web Application Firewalls:

Erl Thomas on SOA GOvernance, another timeless reference:

Thursday, April 19, 2012


"...Every great magic trick consists of three parts or acts..."

The first part is called "The Pledge". The magician shows you something ordinary: a deck of cards, a bird or a man. He shows you this object. Perhaps he asks you to inspect it to see if it is indeed real, unaltered, normal. But of course... it probably isn't.

The second act is called "The Turn". The magician takes the ordinary something and makes it do something extraordinary. Now you're looking for the secret... but you won't find it, because of course you're not really looking. You don't really want to know. You want to be fooled. But you wouldn't clap yet. Because making something disappear isn't enough; you have to bring it back.

That's why every magic trick has a third act, the hardest part, the part we call "The Prestige." ..."

Wirespeed -- AutnN, AuthZ, SAML, RESTFul Services, Certificate Services, XACML, Cloud Sourced Data, a virtual directory integrating numerous attribute stores, controlling access to master data, etc...with less than two milliseconds of latency?

With 150 SOA services and over 600 operations?

 Across eleven different software development teams, on five continents?

That, my son is the Prestige!

The passing of the "...thin, white Duke..." will be felt for a long, long time...