Thursday, May 15, 2014

A while back, I asked if Satya Nadella was going to reverse MSs decision to stop publishing security patches for XP, for free. I didn't get a call or email from Mr. Nadella and MS did not change their overall plan.

That said, MS decided to release the big Internet Explorer patch and include XP. This is a particularly big bug and would be devastating to the web, if left unpatched.

I am curious how thosewho are paying millions for XP support feel about the rest of us getting this for free.

Thank you Satya Nadella for saving the web. I look forward to the next XP security update. I know you will do the right thing when the next big bug comes.

Sunday, February 23, 2014

In my last post, I promised to make fun of companies based on their job postings. Some are silly, some are crazy, and some are unintentionally telling about a companies culture... A word to HR and recruiting, don't let your job ads destroy your company's facade of hugeness.

Enter Caradigm a joint venture between Microsoft and GE! From the press release, this seems to be all about real-time healthcare data. They are talking about interoperability and collaboration with patient data. Done right, this is great stuff, however, we are talking about highly sensitive personal data in a very regulated space, in terms of data security.

Microsoft and GE are two of America's largest companies. I'm sure they have thought this all through... Caradigm is hiring the Information Security Manager. Copy here. While this role sounds like the manager of all InfoSec at Caradigm, surely they mean Manager in Information Security. The top InfoSec role at a company of this stature, with its hands in or on so much highly regulated data, must be a VP or maybe even a C level role. Then again, maybe they didn't think it all through and don't think security is important enough to pay a high salary for.

Friday, February 21, 2014

I get a lot of recruiters emailing me and I get job postings in my RSS feeds. Many of these postings are unintentionally funny, some are downright embarrassing, and some just leak a lot of information about a company.

I've decided to start posting some of these with commentary. The one that finally made this decision for me is from Amazon.com . A copy can be found here. I've added bold for emphasis.

Sure, there are plenty of 2014 Grads with expertise in the book sense and maybe some even in a more practical sense, but, really how does a grad get to a place where their college and work lives intersect with a large 24x7 operation? Maybe I need to open my mind. Maybe Amazon wants a 12th year senior who has been working in enterprise architecture while going to school at night? That eliminates the ageism too!!

Sunday, February 9, 2014

If you have worked for Microsoft, or any huge company, this
will be no surprise; Microsoft has many groups working against each other or at
least spending dollars in one department that could save or make millions in
another. It’s not easy to align everything in a large company, especially when
it has been run by the worst
CEO in America for so long. Microsoft is regularly in the news “shuttingdownbotnets”
anddoing
other great pro-bono work to make the web safer. I applaud this!

Yet, in the core operating systems orgs, they have let
Windows XP, still the second most used
desktop OS, lag behind in security and will stop
issuing patches in April of 2014. There is nothing wrong with XP, even the
MS page on its retirement makes it clear that they don’t have to support it, by
law, so they won’t. There are no claims related to it not being good or safe. I
read it as, “There is no money in it for us, so we will spend the resources in
a money making area”. If you add no context, this is a totally rational
business decision. I won’t pretend to have all the data on the financial and opportunity
costs of patching XP and enhancing it. I have no idea how much money it costs
Microsoft to fund the groups that take down botnets. I also don’t know who the
users of XP are, but I expect they are those who can’t afford to upgrade. This
may be due to the cost of the OS, lack of skills to safely upgrade, or in the
case of businesses, economy of scale making it very expensive.

Figure 1 All OSs on the Web

Figure 2 Windows OS Breakdown

Here is what I do know. MS will continue to support Server
2003 until
July 2015. XP and Server 2003 are mostly built on the same code base, so
patching XP isn’t a complete diversion from their business. If MS stops
patching the OS that is nearly 30% of the desktop market, XP will become the most
researched and exploited OS on the web in fairly short order. The MS team that
is taking down botnets will sure have their hands full then. Maybe MS thinks
that the fear of no patches will finally get users to upgrade. In the case of
the enterprise, I would think so. In the case of small businesses and individuals,
I expect this to be a boon for little IT shops; removing viruses and selling
cheap fixes like host based firewalls, more anti-virus, anti-malware, and Advanced
Persistent Controls.

Considering that Microsoft has zero legal or contractual obligations
to improve or maintain XP, perhaps they can write off the cost of not turning
the internet into a XP infested filthy virus zone. OK, intentional hyperbole
aside, I vehemently urge Mr. Nadella to throw his predecessor under the bus and
take up the cause of keeping XP healthy. This doesn’t just mean patching; it
means a few basic enhancements that are needed.

OK, when I say, “there is nothing wrong with XP”, I know, it
doesn’t have Address
Space Layout Randomization and User Account
Control, and many other benefits of post-XP OSs. Let’s not confuse the “need”
for the next best OS for an actual need to get off a dangerous OS. I guess XP
will be that OS soon, if Mr. Nadella doesn’t reconsider.

My in-depth focus on security is mainly around applied
cryptography and identity management, so I welcome other suggestions in the
comments. Below is my wish list for XP enhancements.

Saturday, January 11, 2014

Disclaimer,
Godaddy made me angry with a billing issue. This is what caused me to
look into the value I get from them. While my language may be angry and
inflammatory, the facts are not disputable. I have informed them about
their messed up SMTP TLS, but have not heard back.

Try to send
a secure mail to Godaddy hosted addresses and they will return this message

Sample server certificate, do not use on
production systems!

Maybe they are hosting customers’ mail on non-production
systems. For additional irony, they are hosted in the domain,
secureserver.net.

farmtomarketcreations.com.
3600 IN MX 0
smtp.secureserver.net.

farmtomarketcreations.com.
3600 IN MX 10
mailstore1.secureserver.net.

Even more irony!!!! Godaddy doesn’t even use their own
hosting for email, they use Microsoft!

godaddy.com.
3600 IN MX 0
godaddy-com.mail.protection.outlook.com.

OK, so this could be that they just use MSs
Cloud Anti-Spam and then relay the spam free mail into their systems, but I
am dubious.

A quick word about SMTP and TLS.It is a great way to keep mail more secure because
it does not require an end user to know anything or that it is even there.It just requires mildly qualified techs to
configure their mail servers correctly. TLS, done right, will protect the message in
transit from one mail system to the next.

Back to the hosting I pay for. While the MX records do
not change for my hosting, the corresponding A records
change a bit, and multiple tests against the same IP render different results,
in terms of TLS support. It appears they use technologies like global traffic
management, round robin DNS, and load balancers, and every host was configured
by a different incompetent tech.

Their MX records for both names seem to correspond to the
same 4 IPs

smtp.secureserver.net.
300 IN
A 72.167.238.201

smtp.secureserver.net.
300 IN
A 72.167.238.29

smtp.secureserver.net.
300 IN
A 68.178.213.37

smtp.secureserver.net.
300 IN
A 216.69.186.201

mailstore1.secureserver.net.
300 IN A
68.178.213.37

mailstore1.secureserver.net.
300 IN A
216.69.186.201

mailstore1.secureserver.net.
300 IN A
72.167.238.201

mailstore1.secureserver.net.
300 IN A
72.167.238.29

Here’s what CheckTLS shows me over a decent number of tests. Never a score above 68 and never once a valid SSL certificate.
Of 18 tests, 2/3rds fail to even allow TLS.

So, let’s look at the hosts that do offer up SSL/TLS
certificates. First, they send their Root certificate twice, adding
to handshake time and size. The root and SSL certs are both 1024
bit. We already covered the clearly stated “Do not use”. The
SSL certificate is good for 10 years? At least it is not expired.
:-P Crazy… Finally, the subject common name on the SSL certificate doesn’t
match any of their server names. I guess they can’t afford
certificates… Wait, isn’t Godaddy an SSL cert provider?

Monday, May 20, 2013

Understanding Certificates and SSL/TLS long ago became an IT
fundamental.

Somehow, the industry seems to have not noticed. In my
quest to take fewer calls on this stuff, here is my attempt to help demystify
all the certificates involved in Client SSL/Mutual TLS. I seem to be spending
2+ hours a day on the phone talking web and server admins through this stuff.

The reason I am doing this is because Google failed me. There
are a lot of docs that focus on all the other aspects of the SSL/TLS negotiation,
but none of them focuses on the certificates and what they do for us. Microsoft
has one of the better
papers on SSL/TLS, but there is a lot lacking around the certificates and
the SSL/TLS handshakes are overly summarized.

Here is the handshake that MS shows us.

While this may be a four message handshake, there are a few
different conversations taking place, simultaneously, in the handshake. The
conversations and their certificate requirements are more easily understood
when they are pulled out of the stick context of the message format.

I will say that I am doing a bit of summarizing. SSL/TLS
has four major components: authentication, message integrity, key negotiation
and encryption. This post focuses heavily on the authentication aspect. I am
lumping SSL and TLS together as the basic functions of the negotiations are the
same, only the implementation details vary a bit. I am also leaving out a bit
about session key generation.

I break the handshake down into 4 different conversations.

A.Hellos

a.The
client tells the server that it wants to go secure and offers the suite of
ciphers it supports.

b.If
EDH is used, then the RSA/DSS key is used to block MITM of the key negotiation.

c.If
RSA key negotiation is used, the client encrypts its initial key material with
the public key on the server SSL certificates, assuming cert and chain
validation succeeded.

D.Client
Certificate presentations

a.The
server issues a Certificate Request. This lists the key types allowed on the
certificate and a list of Distinguished Names (DNs). These DNs are used as a
hint to help the client determine which of its many possible certificates is
the “right” one.

b.The
client selects a certificate, for which it MUST have the private key, and sends
the certificate to the server.

c.The
client sends data that is signed using its private key, proving it holds the
certificate in question.

d.The
server checks the signature. If the signature passes, the server may be
configured to pass/fail the client based on data in the certificate. Often the
certificate serial number or Subject DN must match a static list, or the
certificate must be one that is on file. The decision to pass/fail the client
cert is not specified in any RFC.

Certificates Needed

Client

Server

A - Hellos

None

None

B - Server Certificate

Root CA Cert for Trust

SSL Cert and Chain to send

C - Key Exchange

Public key from Server Cert

Private key for Server Cert

D - Client Auth

Client Cert and Private key

Client cert for explicit trust or CA cert to implicit trust. Cert
values MAY be checked.

Client and Server Perspective

One often forgotten part of this is that when there are two
parties, the role of client and server may change. For instance, let's say A
pushes a full DB copy every night to B, and then B pulls deltas hourly during
the day. In this scheme, at night, B is the server, but during the day, B is
the client. This means that both parties need a cert and a server cert with
chain, and they need to know how to implicitly or explicitly trust other
clients, and they need Root CA certs so they can trust the server cert when
they are the client.

Summary

Take the time to understand how your connections are
established and it is fairly easy to figure out which certificates are used
when. When it comes to figuring out what is wrong, you can usually figure out
the issue by where the handshake fails. The handshake failures usually can
only be seen via packet captures.

Friday, March 29, 2013

This is a post that is long overdue. The IT industry went
through a revolution and most people in IT missed it and are still missing it.

If you are in any form of IT related job, you are in the
information security field.

You may say, “No, I’m just an IT Project Manager (analyst,
whatever), security is another team”. You are wrong and your career is heading
towards a cliff.

It only takes a tiny bit of Googling to realize that
everyone is getting hacked. Even the biggies, RSA, Microsoft,
Facebook,
Symantec,
and Apple
aren’t immune. There are too many actors with too many motivations. If it is
connected to the web, there is either money in hacking it, or it can be used as
a foothold to hack for money. If it’s connected to the web, there is probably
someone with a social or political agenda that makes it a target and if not, it
is a platform for the hacktivists
to leverage. On top of the myriad of highly skilled and motivated attackers, there
are thousands off wannabe
hackers simply looking for low hanging fruit to test their skills or to get
a thrill. Even if you don’t have a penny to your name, your computing power
is a commodity if it can be added to a botnet. Hopefully, you already know that
it’s a given that everyone is a target. If you still need persuading on this
point--don’t worry, there are plenty of Wal-Marts that need greeters. Get your
app in early. (That’s “app” as in “application”, which is a paper form you will
fill out with a pen. You won’t need LinkedIn for this.—The Editor)

So, why is security your job? Every day (week if you are a
slacker?) you make decisions that impact security. It doesn’t matter if you
specialize in a niche, like UI or UX; or something broad, like program or
project management. If you are working with data in any way, that data has
value to your organization. There will certainly be negative impact if the
data is compromised or corrupted. Even if you run or maintain a static website
in which the content is public and can easily be restored if lost, you don’t
want your system to be a foothold into your important systems or take part in a
DDoS attack.

Your Role

Backup Operators – Don’t lose the data and
don’t lose those unencrypted backup files. This role should be a no brainer.
This role has Confidentiality, Integrity, and Availability components.

Systems Administrators – Once again, this is a
no brainer. SAs have all the access themselves and they configure access to
ALL of your data. Remember, all of your applications sit on a host that an SA
“owns”.

DBAs and DBOs – Please, for the love of all
that is good, you guys MUST know you have to protect that data. Do you??

Project and Program Managers – I know lumping
you guys onto one line will get me all sorts of hate mail. You guys decide
things like what use cases exist, for what users, accessing what data. You
decide whether to engage formal security teams for assistance. You decide to
cut product or project scope, and everyone knows security is the first to get
cut.

Developers – You guys are the worst. Yeah,
I’m saying it. Inventing your own “cryptography”, passwords in log files,
backdoors, assuming users will use your apps the way you want them to, and on
and on. Seriously devs, get your acts together.

Network Engineers – I think this is the only
role that most folks actually think of as a security role. In fact, this role
is the least interesting in terms of security roles. Read those manuals and
change those default passwords. And stop using self-signed
certs. Can you really not remember how a MITM attack works long enough to
say to a manager: “Wait, we need a real cert on that appliance admin portal
page”? You know what, if you can’t explain to a manager what a MITM attack is
and why your choice of cert matters, you’re part of the problem.

Your day to day job may be focused on something else, but it
is only a matter of time until IT folks start getting fired for massively bad security
lapses. If it is on the OWASP
Top 10 or the SANS Top
25 and you don’t know a bit about it, you may want to pick up that Wal-Mart
job app. No one is asking you to figure everything out about security, but
you need to at least understand some basics and keep your eyes out. If you do
run a system, you’d better become a security expert in the context of that
system.