Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts

Monday, December 14, 2020

SolarWinds, FireEye, and Russian Intelligence Compromise the entire damn world...

Ok folks, this one is the real deal... I believe that the SolarWinds global supply chain compromise incident disclosed yesterday, is now the most severe, and most widespread information security comprise incident ever publicly disclosed. 

I can only think of one other that is even close... the RSA compromise... and from what was actually publicly disclosed (vs. what many of us in the field know to have been compromised but cannot officially confirm or disclose)... honestly... this may be worse. From all appearances, and the implications thereof, it may be MUCH worse in fact. 

SolarWinds is a major component of the infrastructure that runs... everything really. 300,000 organizations may have been compromised by this... note, compromised not necessarily exploited... SolarWinds is used by a lot of major service providers, ISPs, ASPs, SaaS providers, Managed Service Providers in the networking, security, and every other space... It's everywhere, and when you look at the details of the compromise... yeah, this could be EXTREMELY bad. 

For information and review... The various official notices and responses to the SolarWinds global supply chain compromise incident:

The emergency CERT alert issued appx. 2200est last night:

https://us-cert.cisa.gov/ncas/current-activity/2020/12/13/active-exploitation-solarwinds-software

The DHS-CISA (Homeland Security Cybersecurity and Infrastructure Security Agency) Emergency Directive for the compromise.

https://cyber.dhs.gov/ed/21-01/

This is the solarwinds official advisory and recommendations:

https://www.solarwinds.com/securityadvisory

Here's the FireEye advisory and recommendations:

https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html

Here's the Microsoft Advisory and recommendations:

https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/

Here's the recommended detection and mitigation countermeasures, rulesets, and criteria... as published by FireEye and recommended by the CISA:

https://github.com/fireeye/sunburst_countermeasures

And the recommendations to detect persistence in a compromise event from MITRE-ATTACK

https://attack.mitre.org/tactics/TA0003/

Saturday, March 09, 2019

Title 2 Regulation Isn't Net Neutrality... but it IS Warrantless Wiretapping...

Since it's coming around again...

...STOP SPREADING THE DELIBERATE FRAUD THAT TITLE 2 REGULATION IS NET NEUTRALITY...


It isn't. It has literally NOTHING to do with net neutrality.

Net neutrality is the SELF GOVERNING principle, that all network traffic between service providers and their customers, is the same. Traffic is traffic regardless of the content... except that certain types of latency sensitive traffic can be prioritized, and certain types of low priority non-sensitive traffic can be deprioritized, for network and bandwidth management purposes, and hostile or harmful traffic can be throttled or blocked, to prevent service degradation and the like.

This has, until recently, always been self enforced. Recently, some very large service providers have attempted to double dip, by trying to charge some very large content providers like Netflix, who use up LOT of bandwidth, but are not those ISPs direct customers for their primary data centers etc... That's double dipping, because those ISPs already charge peering interconnect fees, to the ISPs that Netflix already pays for their internet upload capacity.

Again, up until recently, if an ISP tried to treat any other ISP or organizations traffic worse than everyone else, the other ISPs would do the same for that ISPs traffic... thus nobody broke the rules for very long. That is still MOSTLY true MOST of the time... But a couple of the huge mega ISPs are SO big, that you cant do that anymore or you would slow down very large fractions of ALL internet traffic.

Title 2 regulation does ABSOLUTELY NOTHING to prevent that from happening.

Title 2 regulation allows for two main things... The FCC can set the rates large ISPs charge each other for interconnect peering, and it REQUIRES ALL TELECOMMUNICATION SERVICE COMPANIES (including email and VPN providers according to the Obama admin proposed regs) TO COMPLY WITH WARRANTLESS WIRETAPPING AND METADATA COLLECTION, which is the real reason the government wants it.

The FBI cooked up a plan to collude with other federal agencies, and an at the time cooperative and power grabbing democrat controlled FCC, to rebrand warrantless wiretapping, as net neutrality... which actually is, and always has been, something else entirely.

If you believe in phony net neutrality, its probably not your fault... you have been, and continue to be, deliberately defrauded about the issue.

Friday, September 26, 2014

Shellshocked, Vectors, and Vulnerabilities.

So, the Shellshock vulnerability...

Yes, this one really is the biggest vulnerability to hit UNIX-like systems in decades.

Yes, it is in the wild now, and yes, it IS a major problem.

So yeah... you really do have to pay attention to this one. 

Briefly, many UNIX-like systems, including most Linux systems, Mac OSX, and many others, use, or at least have installed on them, a variant of a program called "bash' (the "Bourne Again SHell").

To say that it's one of the most widely used pieces of software in the world would be a dramatic understatement.

Recently, it has been discovered that most bash variants (and by the way, there are hundreds of them, if not thousands, extending back to 1989), when invoked with certain variables, can be forced to execute malicious code.

There are already patches available for many systems which will either fix or mitigate the problem, but there are literally millions of systems out there, and it will take a lot of time and effort to fix them.

There are also many systems which either can't be fixed for some reason or another, or whose owners don't even know that there is a problem.

These days, just about every piece of computing hardware out there that isn't an actual Windows server or PC,  runs a UNIX-like OS; and many of those have some variant of the software in question installed on them by default.  Even if it's not actively used on the system, many systems have it installed by default, and few bother to remove it.

Even if you don't run any UNIX-like boxes, your vendors, your partners, your bank, your power company, your... everything... runs them.

...Hell, your TV or stereo might be running linux these days, and your router probably is.

Do YOU know what operating system is running on every single piece of computing hardware in YOUR company? In every embedded system? In your printers, your photocopiers?

Also, because this vulnerability extends back so far, it's entirely possible... actually it's a damn near certainty... that the code containing the vulnerability in question has been reused in other software (including other shells not considered bash variants, and other entirely unrelated software); which may now also be vulnerable.

So, the gory details...

https://www.us-cert.gov/ncas/alerts/TA14-268A

Read the CERT link, then read this:

http://arstechnica.com/security/2014/09/bug-in-bash-shell-creates-big-security-hole-on-anything-with-nix-in-it/

And this;

http://arstechnica.com/security/2014/09/concern-over-bash-vulnerability-grows-as-exploit-reported-in-the-wild/

And if you want some technical depth, this:

http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html

I don't have much else to add about the vulnerability itself... but I do want to talk about a common problem with how people think of and respond to issues like this.

Confusing Vectors with Vulnerabilities.

I'm noticing a lot of folks out there seem to think that because they're not running a web server, or that they're not providing services to the internet, that they're not impacted by this vulnerability.

That is absolutely not the case.

It's very important to understand, the attack vector for this vulnerability is not JUST web services; that's just the most common and simplest way to exploit it remotely, and the first exploit seen.

This should be obvious, but any service that may pass unvalidated (or poorly validated) remote input to any external shell or command parser, is a potential point of compromise.

There are any number of common services that may do this, including DHCP and autoproxy config, various SSH configurations, various VPN services, some remote management or configuration services, GIT and other code and content management systems, various file sharing and syncing services, various media services, various backup and archive services...

Also remember the vulnerability applies to local command execution and local services as well, not just remote. This is a vulnerability in a core component of the operating environment, not just in any particular service.

Unlike most other operating systems, where an application or service might perform an external function for itself, or through a system API; because of UNIX-like systems fundamental architecture and long standing convention, almost any process might invoke and pass input to an external command parser or shell for almost any reason. When they do, it's usually the default shell for the system, or for the UID the process runs under, and often that default is bash.

Even if bash is not the default for a system or user, some processes may invoke bash explicitly, to avoid potential environment, syntax, or parsing errors (or simply because that's what the programmer was comfortable with).

Also, even if a process explicitly invokes a command parser or shell other than bash, it is common to find that bash has been aliased or linked to the command for the other shell. In many environments, running the command "sh" will in fact invoke a bash shell.

Finally, as I noted above, bash is so ubiquitous, and the code for it has been around so long; it's entirely likely that other shells and command parsers (and possibly other types of software as well) share this same vulnerability.

Again, these should be obvious, but it's surprising how easily we allow ourselves to overlook or forget the basics.

Don't assume you're safe just because you're not running a web server on the machine, or because the machine isn't providing services to the internet, or because you're " not using bash".

Address the vulnerability, not JUST the vector.

Monday, April 28, 2014

Flash Fry

So, as happens every few months, another major vulnerability has been discovered in Adobe Flash:
New Flash flaw could let attackers control Macs, Adobe urges users to update
Adobe on Monday disclosed a new vulnerability in its Flash platform that may allow attackers to remotely take over and control Macs, PCs, and Linux machines and advised users to update their system as quickly as possible. 
This problem was previously thought just to impact IE on Windows, but was proven yesterday to impact all common platforms and browsers.

The most important thing to do, is update your flash right now (and for Chrome users, update your browser as well... it should auto update, but some Mac and Linux users are having problems with autoupdate right now).

If you are unable to update Flash, you need to block or disable it (uninstall it, block it in your browser settings, block it with a plugin or security software etc...). This WILL break a lot of web sites, so be prepared.

Updating though, isn't enough.

Flash... or really any active web content for that matter... has so many major security issues, which you expose to the world every time you visit any web page, or access any open network... that you absolutely must take additional precautions.

Don't just update your flash, use less stupid browsers (chrome and firefox both do just fine for the most part). Never use internet explorer for anything unless you are absolutely required to; and then only use it for the absolute minimum required.

If you are required to use I.E. for work, or a specific site or application, ONLY use it for those things. Use another browser for everything else. Heck, that can be a good security or organization practice anyway, just to avoid mixing data accidentally (like saved passwords or form fill data).

That's step one... or I guess step one and two, counting a browser switch (though I would hope that after the last few years, and the number of times I've warned about it, very few of my readers are using I.E.).

Step three, once you are using a decent browser, you need to use a script blocker, an ad blocker, and a flash blocker. These stop active web content from running on your computer without your permission.

All are available as free plugins, and they only take one button push to install from the builtin plugin search in your browser.

The great thing is, in addition to improving security, they just reduce the general annoyance, stupidity, and irritation of the internet.

For example, they prevent auto-loading auto playing flash video and music, prevent most pop-up and banner ads, prevent some useless and stupid social media overlays... Hell, they even make your computer faster, because all that crap takes up bandwidth, CPU, and memory.

Browsing with ads, scripts, and flash blocked, makes living with the internet better in every way.

For those few sites where blocking tools breaks stuff, all the tools have a little button to pause themselves. If you're going to go to that site a lot, they all have an option to not run whenever you visit that site... Just remember if you manually paused the tool, to manually unpause it before you move on to another site.

It doesn't take a tech wiz to do it... it's no harder than clicking a link in a browser.

Wednesday, December 11, 2013

Google Malware Detection Being Stupid Again



As it was here: http://anarchangel.blogspot.com/2010/09/google-malware-detection-throwing-false.html

and here: http://anarchangel.blogspot.com/2013/02/no-this-blog-is-not-hosting-malware.html
"No, this blog is not hosting malware 
Sometimes googles malware detection gets a little stupid; and they flag completely benign sites as hosting or distributing malware. 
In this case google malware detection is reporting that I am hosting or distributing content from "cooking issues" "a known malware distributor". 
Well, first of all I'm not hosting or distributing content from them; they are (or were, I just removed it) a link in my blogroll nothing more. 
Second, they aren't a known malware distributor, they're the blog of a few instructors at a cooking school who like to mess around with unusual and interesting techniques for producing food. Very good site, I just wish they'd update more often. 
It appears they haven't updated since August... and it's entirely possible that in that time someone has snuck some malware onto their site... But much more likely is that they also have a link to a site, which has a link to a site etc... etc... 
This is the weakness of automated malware detection, automated intrusion detection etc... In fact, this can even be used as a deliberate denial of service attack, getting "content protection" services to block a site (it can be VERY difficult and annoying to get unblocked). 
Anyway, I've pulled the link off my blogroll and everything seems to be fine now, with no more false alarms."
The site in question today, is a link to the blog of Linux and security expert Eric Raymond, and it is most certainly NOT hosting malware.

Tuesday, December 10, 2013

Two completely different things...

...only connected by both being talks@google, that if you like my blog, you MUST watch:

The first is a google talk by Joe Hall, chief technologist for the Center for Democracy and Technology, basically about how they work with regulators to stop bad laws (sorry, embedding was disabled):

http://www.youtube.com/watch?v=L4KQPsrVNv4&feature=share

The second is a talk with man I consider a true genius of common sense and basic wisdom, Nick Offerman:


Trust me on the second... it starts slow, but it's entirely worth it.

Thursday, October 24, 2013

Useful Complexity



...And even then it will be cracked, because GPU based cracking and cracking method optimization, have reduced the time required to crack the entire passwordspace for most passwords down to a matter of minutes, or at worst hours.

According to several recent articles in various industry publications and websites, approximately 85% of all Windows passwords can be recovered in less than 60 minutes, and more than 90% within 24 hours, using only a single multi-core cpu, multi-gpu computer (basically a high end gaming rig).

Using small clusters of multi-cpu many-gpu systems (basically, spend $20,000 on off the shelf hardware) the entirety of the 8 character Windows passwordspace (all possible 0-8 character Windows passwords) can be cracked in a few days, or less.

With the computing power available today, the only useful thing high password complexity does, is make your password harder for a human to guess.

...Unfortunately, the bad part is, that also makes it harder to remember, and harder to enter.

Here's the level of minimum password complexity that is actually useful: 

8 or more characters, not forming any dictionary word or combination of words (including letter substitutions), and including at least one special character.

Anything else is just making your users life more difficult, without actually making them any more secure in the real world.

Ok, so... why is this the "useful level of complexity" ?

Because in the real world, an 8 character password, without any dictionary words or variants on dictionary words, and including at least one special character, requires a cracker to use the entire characterspace to crack your password.

Wait... what? No, that's wrong isn't it? There's 128 ASCII characters, or 255 in the extended character set right? Upper and lower case alphabetic characters, numerals 0-9 and a whole bunch of "special characters"... All of those can be used in passwords right?

Well, yes, theoretically the possible characterspace is 255 characters (or 256 for ISO-8859/UTF-8 encodings).

...Theoretically...

In reality, it's not. First thing is that most password systems don't allow the entire 8 bit characterspace.

While it is theoretically possible to use the entire 8 bit U.S. character set (extended ASCII or UTF-8) in a password (or even to use a multibyte character set), it requires special keyboard codes, and these characters are difficult to enter. Further, most mobile devices do not allow you to enter characters other than those on the standard keyboard (or make it very difficult to do so).

There are 94 or 95 characters available on a standard US keyboard (depending on whether you count the nonbreaking space i.e. the space bar): 10 numerals, 32/33 special characters, and 52 letters (upper and lower case).

By the by, these are generally referred to as the "printable characters", with the remaining characters referred to as "non-printable".

Even if you wanted to use them, accepting that they are difficult to enter and mobile devices may not be able to enter them at all... most password systems exclude unprintable characters, leaving a maximum of 95 possible characters.

For those password systems which allow the non-printable character set, they generally limit passwords to the 7 bit basic ASCII character set (or sometimes ANSI-1 or UTF-7, which are technically different, but include the same characters), which is 128 characters.

Oh and yes, there are non-us character sets, even multibyte character sets that include many thousands of characters, and it's certainly possible to code a system that accepts all of these characters.

... but no-one does.

Even computing systems that accept large character sets for text input (those supporting the Chinese GB18030 standard for example, or a full implementation of UTF-32, with over 1.1 million possible characters), generally only accept a limited subset of characters (usually UTF-8) for passwords (because you can't guarantee compatibility with large character sets across all hardware and software combinations).

So yes, the theoretically possible characterspace is actually many more than 255 characters, but the 95 keyboard characters comprises the entirety of the passwordspace most people might actually use.

Oh and many password systems exclude some or all of the characters !@&*$?/|\ and almost all password systems exclude the nonbreaking space (the space bar), because they can cause problems with parsing. Some actually exclude all special characters, but this is rare now.

What it comes down to, is that the "normal" characterspace is 94 characters.

That would seem to make it even MORE important to use case shift, and numerals; as they comprise 38% of the available characters.

In theory just using lowercase and special characters takes 36 of those 94 characters out, meaning that crackers only need to use 72% of the characterspace to crack your password.

...In theory, it would be better to make them need to use 100%...

...but in reality it doesn't work that way.

Okay... why doesn't more complexity increase security?

At this point, the computational power of multi-gpu cracking system, is enough so that in any serious cracking run, crackers can include the entire alphanumeric space without undue penalty; so including numbers and case changes can help a bit, but not much.

The first cracking run on a password will be optimized for high speed, and will include an optimized dictionary, and tables of common dictionary variations and substitutions (substituting 3 for E, @ or 0 for O etc...). Combined with a full lowercase alpha only run, that only takes a few minutes, to at most a few hours, for the entire 0-8 character passwordspace.

From there, crackers go to brute force, with or without optimizations. The first thing they're going to do is add in the full alphanumeric space, before they add in special characters; and any run that includes special characters will therefore almost certainly include mixed case and numerals.

That means that in a bruteforce attack, whether you included mixed case and numerals in your password or not, the cracker will still try all of them as if you did, and therefore it will take just as long to crack your password as if you did include them.

So, any password with a special character is likely to be slightly more secure than those including numbers and case changes, and unlikely to be less secure (presuming equal length). To put it another way, using a special character (or preferably more than one), has a higher expected security value, than using mixed case and numeric characters.

Yeah, it MIGHT take longer to bruteforce your password if you've got all 3... but your password is going to be one in a hundred, or a thousand, or a million, the cracker is trying to crack all at once; and they're going to run the entire mixed case alphanumeric space, before they even start adding special characters.... and these days "longer" is a few hours, or at most a couple days, not "more than 30 days".

So, unless your password policy is that users change their passwords every week (and that would be a huge support nightmare, causing more lost productivity than any value doing so might provide)... adding any more complexity doesn't significantly increase the security of a password; but does significantly increase the trouble to your users.

Include more complexity if you want to... but don't make it a requirement.

My personal recommendation for how to create good passwords?

Using the first or last letter of each word (or better, both the first AND last letter) in a phrase, poem stanza, song lyric, or other memorable passage, combined with special characters; is generally a good way of producing a pseudorandom non-dictionary string that is of sufficient length to provide reasonable security, but which you can still actually remember.

Include more than one special character, and don't make the specials ONLY the first, last, or middle/joining characters in the password. Also, don't make the only special characters you use, common letter substitutions like $ for S, ! for I etc...

All of these are common optimizations which crackers use to reduce the time it takes to bruteforce a password by the way. Not doing them forces the cracker to bruteforce the entire passwordspace, not just the MUCH reduced optimized space.

Going to more than 8 characters is actually useful, if the password system doesn't drop or ignore the extra characters (many do).

More than 16 characters generally isn't useful for a pseudorandom password, because 16 characters using the 94 character passwordspace, is essentially uncrackable at this time (it's computationally infeasible within a reasonable time horizon). Really any complex pseudorandom password with 12 characters or more is likely to remain computationally infeasible for at least 10 years.

Telephone company studies to determine the ideal length of phone numbers, figured out that human beings are pretty good at remembering strings of 1, 2, 3, and 4 characters, and combinations of those strings (2+3=5, 3+4=7, 3+3+4=10 etc...); with 3 and 4 character strings being the easiest to remember due to something they called "memory chunking" (the human memory seems to run 4/4 time).

Those same studies showed that humans are generally bad at remembering strings of other lengths, more than 4 strings total, and more than 13 characters total (with optimal recall at 3 or fewer strings, and 10 or fewer total characters).

Given that, I say make your passwords 9-12 characters long, with at least two special characters. You can improve your password strength dramatically with every additional character up to 16, but you trade off on memorability.

The standard recommendation is to use a different password for every account; but given the huge number of accounts people often have these days, it seems unrealistic to expect them to remember that many different passwords.

One solution is to use a password manager, which will create a unique strong password for every account, and store them, requiring you only to enter the strong password you created for the password manager itself.

Another solution is to create unique strong passwords for your high security impact accounts (those with banking, credit, legal, and healthcare impact for example), and then to have several other passwords that you use for other security levels, having just one for each level, but changing them at least every 90 days.

Whatever you do, it's always a tradeoff between length and complexity (increased entropy), and memorability and easy of entry.

Speaking of length and memorability... passphrases?

If the password system in question doesn't drop or ignore characters beyond 8, 12, 16 etc... you can also use longer passphrases instead of pseudorandom passwords.

At first glance, this would seem to be an easy way to have a memorable password that is still very long; which is true, but there are some major issues with passphrases that make each character in added length of much less value than in a pseudorandom password.

Multi word phrases using common dictionary words are less secure for an equivalent length, than pseudorandom passwords with special characters, simply because the possible solutionspace for each is very different.

With an 8 character password, in a 94 character passwordspace, there are 6,095,689,385,410,816 possible combinations of characters. There are only about 30,000 8 letter words.

There are between 250,000 and 400,000 words in the english language (depending on what words you count and whose estimates you believe). The average English speaker however only knows 20-40,000 words, and only uses about 2000-4000 words regularly.

Further, English words exhibit very strong letter frequency patterns, which are well understood in statistical analysis (in fact that understanding is critical for cryptanalysis). For example, the average english word is 5 letters long, and more than 80% of english words contain at least two of 6 most common consonants, and at least one of the vowels e, i, or a.

Reducing the dictionary set to common words of 8 letters or fewer, brings your wordspace down from 400,000 to something like 100,000.

These characteristics dramatically reduce the total entropy of passphrases; and dictionary optimized bruteforcing, based on common words, and english letter frequency, can be many orders of magnitude faster than a straight bruteforce.

Essentially, each word in a passphrase provides less than the entropy of a pair of pseudorandom characters.  

In fact, given the reduction in entropy inherent in using dictionary words; if you are going to use a passphrase without increasing the complexity, I would recommend at least 8 words and at least 32 characters (not including the non-breaking space. Longer words are better).

... which really means you should be increasing the complexity. 

The first and most basic thing, is to use at least one word 8 characters or longer, preferably an uncommon one (say... antidisestablishmentarianism for example). This makes the wordspace required to crack your passphrase DRAMATICALLY larger (the average English word is 4.5 characters long. Going from 4-5 character words to an 8 character word increases the cracking space from around 40,000 to over 150,000 words).

Passphrases should include as much of the full 94 character passwordspace as possible; using mixed case, multiple special characters (punctuation is good for that, but because spacing between words is common, it has a lower expected value than other special characters), and if it is easy to remember, and makes sense, numerals. Also, using a special character substitution in more than one word here provides a dramatic increase in entropy that is very worthwhile, particularly if it's not a common substitution.

I would also recommend replacing (os letter substitution with) one or more dictionary words in the phrase with a pseudorandom string. For example, use the first two and/or last two words of the phrase to create a pseudorandom string with the first and last letters.

Increasing word complexity and adding pseudorandom strings to a passphrase of any length more than 5 words or more, and at least 20 characters should make it functionally impossible to bruteforce.

Common words of 3 characters or fewer are actually easier to bruteforce than single additional pseudorandom characters. So you want to average at least 4 characters per word... preferably 5 or more (more than the average word length).

Oh and as spacing is predictable in standard English phrases, make it unpredictable. This results in combination words that together are harder to brute force than the multiple individual words with spaces would be.

Basically... if your pass phrase includes "the" and "end" you should make sure that you've got two 6 letter words in there and make it something like "Always-beTTer intheenD!" (which would be functionally impossible to bruteforce any time in the forseeable future).

At that point you have the same entropy as a pseudorandom string of the same length... it's just easier to remember.

Friday, July 19, 2013

You can no longer pretend your house locks provide actual security

I've been telling people a long time, that the only thing most locks do is keep honest people honest.

Now... I don't want anyone to think I'm against this service, I think it's great... but...

http://shloosl.com/

Pretty much ends any illusion you might have about your locks being secure.

Why? What is Shloosl?

It's a service that copies your keys, from a photograph.


Or rather, two photographs.

Just take a reasonably high res pic of both side of a key, send it to them, and a few days later you get a copy of your key.

... or anyone elses key.

Of course, this has always been a risk, it was just harder to clandestinely copy keys before.

Now... were I an idiot, or a politician (but I repeat myself), I would call for a ban on this "dangerous technology" etc... etc...

I'm not an idiot... and I don't believe in banning things in favor of faux security.

But at this point, you have to understand, any security depending on a key, can be compromised if your key is out of your direct control in any location, for any length of time.


Thursday, July 11, 2013

Cleaning up my crypto

Given the current state of things, I'm cleaning up and updating my crypto regime.

I don't know how many times I've said it, but anything sent in plain text over a wireless network, or across the internet; no matter what your endpoint, last mile, or client to server security might be; is effectively publicly readable information.

Never mind the NSA, half the time script kiddies can read this stuff without too much effort.

It's not so much the data in flight you need to worry about (though that's not exactly invulnerable either), it's what happens to that data once it actually hits a server. It's the data at rest, wherever and however it may be at rest, for however long it may be.

How secure is that server? Is that data stored in plain text? Is it in databases and spools and caches in the clear? Is the data sent from server to server in the clear? Are the backups of all those systems secure?

And for that matter, how secure is your OWN internal network? Your machine may be clean and virus free, and uncompromised... but is your wireless router? Is every computer inside your network just as clean? Are they listening to your communications, or browsing your fileshares?

If you want to protect confidential or higher information, or communicate with any degree of confidentiality; you MUST use strong encryption, preferably both in flight and at rest.

Now, security geeks, cypherpunks, and other professional and enthusiastic amateur paranoids, have known and internalized these things for years; but the general public STILL doesn't really understand them even today.

Maybe the NSA thing will wake some folks up...

Part of the problem though, is that encryption is inconvenient and irritating. Even for a professional like me, there's still a number of things I'd like to use strong encryption for or with; where there either aren't any usable options, or those that are available are a major pain.

It's better today than it used to be however; and at this point I'm going to take advantage of that fact to clean up and simplify.

A few years ago, I was stuck using several different solutions, even just in my personal life, because there weren't well supported cross platform open source implementations and solutions, for the various things I need crypto for. As of now, that's no longer true with some minor exceptions (secure encrypted instant messaging, and encrypted voice communications for example).

I'm now standardizing on GnuPG (or any open source OpenPGP implementation, as they should all be interoperable) and TrueCrypt; because they work well, are well supported, and do what I need them to do, on the platforms I need them.

I've mostly used those two solutions for a while, but had a few others lying around. As of now, I'm 100% on GnuPG and TrueCrypt unless they are unsupported in the application I need encryption for.

Yes, I know, open source purists don't like TrueCrypt because of its licensing terms (it's source available, but not fully redistributable), but as of right now, it's the best cross platform solution I've found for what it does.

I'm also moving my defaults to 4096 bit keys, AES256 and SHA512 (well... they have been for a while now, but I still had some other stuff lying around).

There are more secure algorithms, particularly more secure hashing algorithms out there, but these are the most secure that are widely supported by multiple platforms and devices.

At this point, 1024 bit keys are factorable, within a few hours to a few days, using COTS equipment and software. Simply speaking, 1024 bit keys are no longer secure; and have been deprecated or outright revoked and banned, by most reputable authorities.

In theory 2048 bit keys are not factorable within a "reasonable computational horizon", but we thought the same thing about 1024 bit keys up until the early 2000s. The current "official" government estimate, is that, if computing power increases at approximately the same rate it has averaged over the past ten years, 2048 bit keys will be viable til 2030.

... but until 2003, we thought 1024 bit keys would be viable til at least 2050; and until 2010, we thought they'd be good 'til 2020.

The disadvantage to going to a longer key of course is computational. Longer keys mean more resource use in encipher/decipher... but these days, our devices have CPU to spare.

Most software and devices support 4096 bit keys now, so I decided just to skip 2048 and go to 4096. If I find I have to work with a device/platform/software that only supports 2048, I'll generate a subkey.

Some would ask "why are you exposing your solutions publicly, doesn't that make compromising you easier?"

Well, it could... but I don't believe in security through obscurity.

Any encryption solution is going to have weaknesses, and it is relatively trivial to figure out what tools you are using to encrypt. If you're going to be using crypto with the outside world, you HAVE to expose this (generally speaking)... So really there's little point in trying to hide it. Conversely, listing my solutions, will make it easier for others to use crypto with me.

Now, to the irritating details...

Revocation of all previous keys

As of July 1st, I've issued revocations for the keychains I still have the keypairs for. There are a number of keypairs out there that I don't have the private key of anymore for various reasons.

All keys, signatures, keychains etc... issued or reported for the following identities, addresses, or KeyIDs before July 1st 2013 are invalid:

----- UID/email/KeyID -----

Christopher Jason Byrne IV
Christopher J. Byrne IV
Christopher Byrne
Chris Byrne
Christopher Jason Dinsmore
Christopher J. Dinsmore
Christopher Dinsmore
Chris Dinsmore

chris@chrisbyrne.com
cbyrneiv@gmail.com
cbyrneiv@hotmail.com
cbyrneiv@yahoo.com
cbyrneiv@aol.com
chris@byrne.net
jobs@chrisbyrne.com
cbyrneiv@securedefense.net
christopher.byrne@wellsfargo.com
christopher.byrne@hp.com
christ.byrne@avistacorp.com
cbyrne@insl.ie
cbyrne@dataedge.ie
christopher.byrne@lmco.com
byrnec@lmco.com
dinsmoc@mediaone.net
dinsmoc@yahoo.com
dinsmoc@aol.com
dinsmoc@pr.erau.edu
dinsmoc@erau.edu

0E818683
DDA5B467
9CCD73A0
F1467FEE
3EC03718
CB0C43FB
67A82CF2
04ADC0C6
89A7A21D
24B839DD

----- UID/email/KeyID -----

My current valid key is available via public keyservers

keyID: 85BF0B25
Issue date: July 2nd 2013
NAME/UID: Christopher Byrne < cbyrneiv@gmail.com >
NAME/UID: Christopher Byrne < cbyrneiv@hotmail.com >
NAME/UID: Christopher Byrne < chris@chrisbyrne.com >

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)

mQINBFHScT0BEAD3KOfgiz8rquiqSFR+muTOBThixWaawMcNVKOJ8LclbINUUGb4
5d3EEX4u8vlVRZLFOwc3B6mJGlDfCSd0JnX7kk/K67EQ2uh9dQCx+Odb+Brhxb6V
YYBZMbCB0BFlk5jpPhO/Me06FV8L2u0s0Q6O37ELQm8Z+bEBNBFK6rIX6MaWmKpl
vUMcNJB+rjeFzV4XkjJo9+T/g5qsgifR6YieHgO2Dzpf3RrWw/LZZzOy+TuLYhi9
df8OwT5KVyLVQAYXIa+jhzAcc4wQt+gmDE5j08Iv94iGZZkXrRMTTLAbJSbzVAOl
fiSRDHINkNIGD7adUltEel5pYLB/V+yckjLMzA5+5i53XeFYrmDEVpmB8/2UfVyc
hONBRsMWmANjIsVnymO6BSpGnfMDXRyorfeaFTgFw79EBH2dq+zcVGKagTLHb2IY
DvvxaXORmLYb3ndiGtoQLKFPlhTGHxdDJAuRWHsRWLpqyjLswp16kl9OllR/95bl
vKyTjZoxB3+F4Ko99Y000Cr6D8WYWXTGiHcNQQbj8WYryT5jNzZTfJU3+UpxjC2K
jqOmNB3l6rNzKWo0NCkB+bcCEnMaO+/TtbKGkC0hkMuvpH9+ZTTraweunSnBV6Va
cVOcIM7o34DZmk8uQIT7Z+3dkFEjCMiFWFM6blr1HBDS5xIPSgsuLxt3dwARAQAB
tCZDaHJpc3RvcGhlciBCeXJuZSA8Y2J5cm5laXZAZ21haWwuY29tPokCOgQTAQoA
JAIbLwIeAQIXgAULCQgHAwUVCgkICwUWAgMBAAUCUd5kvQIZAQAKCRDNj7W9hb8L
JUTnEADTl6N6bXauid9GPWBBPolaKFclB3cx6tN7GNZj4o/WGxJA6agm0V2scTYT
Ty5TWmDJjEkK1peri7Ellhy2vKRxlEyd6uWnPPF0IDI/f+kJyhl7itcTN0+UUtVG
rknBYKGXFySbJV6iYEQaHgSCYeVVFvri+sMR7ApKiKEX87CTsIvuZolrl4n8JCmc
p3GgpCl0gpNlOgWlw+knajsLKRTuG+sHUdh7mxHftb35VII6SmcAcYBBpbkriZEO
ENrKV6kEHuFqGFNpvV1F3PJVXud5yh0xZ0/hRNbUjaV0v15LapotKLc80xeO3U5b
JU0siVsrl6e25OD3WtXWkdITiNAIMyjq2wwoQB76hZabfowE/WND8xCsXkj4b/rg
eitnVEsbwa33s1ev7vyi/GD+LFWunUfC0iYXuxwa9w23p0DVNp1JZeeRXDQXMmFB
8kw/KVlQDk++/newTMwH1ZN2mTythmGhgtll6MIrvlojGtZbFQWPuNFbqL3TkT32
2ZDjesl8euYxdbAEaYWHWZIDz+8jdVkfzOxipSA8ZTD/76tEY+es1/NLgo+8BeUa
ujmc1tqWf985MvWQ8QacWhqj4HTKIAngO0JshJlCr2FkHn6Y/Itdb9VBxX7k7INh
Cy36i11VL+takV5ikJdGruIGA6KSWkzlRbirpS1POrUv3XR4zrQoQ2hyaXN0b3Bo
ZXIgQnlybmUgPGNocmlzQGNocmlzYnlybmUuY29tPokCNwQTAQoAIQUCUd5ktwIb
LwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRDNj7W9hb8LJRx8D/9sJyJUcNWZ
AKXq4o01hBHvdW3ACctq16Q+kMk1BoRtvzwfZZFJu0eryBf8zeUki0mKdFJmlS4J
VIwA/Wl/smgE2Or9YNmzzPBJNI9gmPOr5CxDFwJEjpsgvnfLxbLx8QjVfHb36pKR
vdK+eoS4TT89G+3DmavgWCEpRgH5aiajZ8hMIFEf2HCiLXlvIwxswyz7JyhmszRe
UiVhgQVWD9VQCg9HV2C+EEVQ8b5783bfelV/LP0KW+X8rj6JrRcmA6hm48zTPBMj
9cUs+WgfodXwewVop4DRq52SgT0EfdwbalpsHoFdozcd2W3RrJjhFD/mJOL7rOUm
3It2Nzg3UFBxdjbpTvtrylYIStnUC5j3+3sI1krMFUgelG+yxX0LqTczK9f7IiI9
ikvDt6Ss7I1w2IwMckbK3+7E2z8tvwEQfw0aYVEJerwLdDHqFmFDVBiPxvd7Maag
20lqCF4E8McsRLFPvQHPJiRB+g6cOzZX9t1zt/5eXzDMcTCG0RXchvJ9tQqU8B4I
lWcO2aDocDVp65ppXSRz6wXCKJJs50dC3ZAcDp1i8cjl7s4XtGBieui8hlxdVgJy
IHFm0nDjWu56Sj62rvfvsUQ8FJuyk3z6X5wB6ZBs+oQ4lzIFiL4+ut7pnyUf5z3h
wrxk/n/BKAHpTKimw/tVp2EV/mPGPdYeE7QoQ2hyaXN0b3BoZXIgQnlybmUgPGNi
eXJuZWl2QGhvdG1haWwuY29tPokCNwQTAQoAIQUCUd5krQIbLwULCQgHAwUVCgkI
CwUWAgMBAAIeAQIXgAAKCRDNj7W9hb8LJR6LEADyC3KB9cxnTfn1jBirYGLFvdmP
uhYPz4++bkGOhWNTfOaZSuAFgvJDXWMWcc8K9oHFZe+XYw7h2hTdSUlUmMV9h+7P
KasoebfhxHoVi6Oy5eU94OnAioanies0RZZmVny7LJTeyah3oGQ1SNesNXirVwEp
amvdZLvlGkCmaYsDtgzJkaqxoU4pVXGIY2Nz62iw70Qy4Eo9Z0JZdQaXlpw1X94P
sVlWV10dKq6yT3QWDP5pTnA3XKkHWem/paSWea3hhHhgx/6PDaF8jABuP7Ew/ADp
RwLV3+oMosZMp8Qh6fNk9GuPeH6rNEUPXyZnlLFOyJGCHp5YU9vsVj3yHdz6dfmO
s6M41NKjjIKg+EiW2sM4FhlDRMFtnyKaS78WSy8oFWyzecCB2VNbevj3m/q34Xp/
PlC+Qv/lIfZRZyv1nAoImQs+nwn23NFjmxX5joUsfuV7M8F+xRnf1OnWv19LmNCF
EjutJ5MEU/MMcx/nJiYq2X4Mxmt/UkExwO3wn+JwKUDZyxpGR7dn8mqUEmY1HcPf
bzacOy7r1hWbhwwvlQd0qf/sRyqSV76qObafM5mjY2DPvfhxYVAz2LyQuhAHg9ST
EafEPFtW2EPlN3hkmsIEhTOaXff+rmcivaa0UwhZpIMhejaMSAmm5nTE14l50dYh
MjrXnjyk8qqoQfvFEtHUxtTEARAAAQEAAAAAAAAAAAAAAAD/2P/gABBKRklGAAEB
AQBgAGAAAP/bAEMACAYGBwYFCAcHBwkJCAoMFA0MCwsMGRITDxQdGh8eHRocHCAk
LicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv/bAEMBCQkJDAsMGA0NGDIhHCEy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
Mv/AABEIAO8A8wMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUG
BwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGR
oQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZX
WFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0
tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAf
AQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAAB
AncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZ
GiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SF
hoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY
2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/ALtFFFYmwlBpaQ0DEooo
pDEpKU0hpAIabTqaaBiGm55pxppFIBrdaCcU6mkUikHWmmnGmmkMaaQ0ppDQA000
040ygANNNKaQ0AJSUE0maAClApKUUkDFpKWkqiQxS4xSUhagBc0UzNFFhG9SU6kN
aECUlLSUhhSGlpKBiUhp1JSAbSGnGmmgY00lONQXFxFaQPPPIEiQZZj2pDHnjJPA
Fc3qfjOwsmaK2Bu5RwdpwgP17/hXN654kutZka3tt0NnnG0HBf8A3j/Ssu3sizDg
HPeiwJNmtP4v1e5OIikAPQRpk/mar/2xrLMW+3T7h1G6p4dNYpnHP5YqVrA5xwB0
6UmzVU11C28XapbMBcItwg67hg/mK6LTfEtjqJEZbyJz/BIev0NctJAFONpwf4cd
aozWYcAovP8AKldDdPsenGmmuM0HxHJaSJZag+YScJKx5T2PtXZE5HFMzENIaU0l
IBpoopKAFpw6U2lzxSBhRmkzSE1RIE0maKSmIKKSimI6A0UUhqiQpKM0lAwopCaM
0gCiiikMQ0006kNIYwkAEk4A6muB8Sao+qziCEkWqHgf3j6mum8R3jQWQt4zh5+D
jso6/wCFYGn2KzENKCecCgqKuzBjtSOFx07dq0ILdVUDcGx1Y9hW+NHiaTjj6VUm
0O4EgRCdpbkj0zQa8rQ9FVYRt+h7nNP+zsQxXJY9zjg/0pwglR0Eq4I6du3WpopU
DY8w7ycH0xRYEVXsg4YZU7ecnpWVdW7pnqR6L2roJRiMoBsY5PB4J/CqLWcsuR5L
H9RUM0WxzVxbLJu+Xr6jBrpvDWpNLALC4P72Ifuyf4l9PqKZHpMjMTLCVXuSMf8A
66oSQPY3SyR8PG2RSUugpwurnYGkJqOKZZ4UlT7rgEU6qMBc0maTNITQApNLnimU
oNCExc0hooqiQpKKSgBaKSimI6DNITRSGqJDrRSE0gOaBi0lBNJmgBaKaTRmkxjj
TScUE00mkM5TxA5l1ry88JGoH481Nax7FXjBNM1ZMeIsno8Sn+Y/pV9ABsx27Umz
akupPCpJBPBq/EhxyOTVaNRkfSr0RAAz2qLnUtiza2cFxMPNQEgcVLfeHrGTMwTb
kdjxmltXAYMeo6VdlnV4x2H1rRNWMZJ8xmw2EEQwI1A+lDqqcKoH0FWTKoU8VVkc
+nBrKTRtFMoXRytc5qFtulZgOK6WcZWsrUBtQkDtWd9SpK6KWknZavDz8jnGfQ81
fzWdpj7pLjn+7/WtDNbLY4ZaMCaSikNBIE0oNMNLnimhMfmkJpuaTNUSOzSZpozn
rxS5oAWikooA3+1JmlptWQKeaQmkpKQxSaM0maM0DDvRRSUgFzSUZpCaQzmdRuBP
rKts2iNdmT35NXIGDsOay9QJGqTHOQXJwe3+cU63u1MZKklhzgUmjeDSOjiAY/pV
2KLoM1zEerGHmRGH4Vo22v28jAbsGp5UbqodAikAfyp24k8jiqcOpxsM5zUh1KLp
tAFHKVcsEEg+lQSDA681DJq0A/iUDoMmqkmqQE4MgzUuI1MmmOAeay9RbdasB1Aq
Z9QiJZSevftVC5nBt32kE5wMd6ztqW2mjP0Jsi5Zm5LgVsVkWsbRA28WTvkDSv8A
59/0rXJrWOxxVY2aYZppNITSE1RkKTS5pmaXNNCY7NNzSZozTELnik3gUh5FMIzQ
A8SD1oqPaKKYHSbqQk00mkDHvxVEDs0m6kLUzOCaBkmaKbkUZpAONITSE0x5FRGd
2CqoyWJwAPegY8msnWfEVhoiYncvORlYU+8fr6D61zuveOFTdb6SQzdGuCOB/ujv
9a4OWSSeVnkdnkc5ZmOST7mrjTvqyJT7Hcm4uNWaO7jURO8gkZFJIx6e9Xns5TM0
QheEqNwYE7Tn29apaWfK2ID91QPyrqAxkxIASxHzVizshG6OVk0y9lgmxfSiX/ln
tOAPYipdP0WSOydrieU3bNldj5VR75PNdIbRH+baQe/FI8aQRM2GJx0xTU9LDdHW
5jaZLcNdraIHdjk7pTsx+HNXtVe4s2SNlT96cKUfJ/IgUmmRxjU2uVX524OKu6xa
x3s8TOMmNtw96iUrM2jTlynPNp9xLG7NNIjFCY8g8t788VVsYNUAk8+1QFB8u5my
5/A8V2MVut0mGIUjtmnHTCvDSHHfpT9orbGbpSve5yomlIAktbhHJ2hF+cE/4VZt
LO7hkIlTZAq5w3JL/X0xXSRwRRKNnUck1X1KYNGxPWsnK5vGnZmda48sMDyXbI9u
KslqxF1CKzUPMwRHfbuPY4z/AErTjmjmXdFIkg9VYGtILQ5K79+xMTTSaYWpC1UY
j804moGlVPmdgo9ScVn3fiLTrXIM/mMOyDNNCZrZozXHXXjNuRa2wHozmse58Q6l
dZDXDKp7JxV8rI5kehT3dvbgmaeNB/tNWZL4o0uNwgmZyTjKrkV588jyHLuzH1Jz
SJzIoHXIp8gnM9aBJAI6GimoSEXI5wKKks6AkUhNNPtSHPrTJHUhNNFOwTQAgajd
VW71OwsQTc3cUeOxbn8q4/X/ABuWBttIJUY+a4Yc/RR/Wmk2DaR1Ora7Y6PFuuZc
yEfLCvLt+HYe5rznW/Et7rTFJG8q2B+WFDx+J7msaSSSV2kkdndjksxyT+NMyc1r
GCRk5Nik0AUmc0A1RJ1ulXGVhbOcqO9dbaTZA5rz7R58qI88o3H0NdnYzcCuWS1P
RpT0TOnhkyvNVtVfFlIeh6D61HBNnHTFM1QGW0xGy+YGBGTgH2qDodtyvpETCYgj
uOa1NRUo+MciudtNQvLa5yscUgXqEbn9etWb3XLybaVtgoyBumO39OtKUboqFRI1
NPkKs4ODg8VoOdyg4APtWNpAlkSWa4ePc5+UJ/OrrS7QRU9LFO17iTSbQeeKwtUn
JTaDyeK0Lqb5TWDeyjczMcKozmpCUtDmfEF2xljs1xsUCRj79BWTHNJCweKRo27F
Tg0t1Obq6lnP8bZHsO1RZruhG0Ujx6s+abZ0Fj4rurfCXYFwn97ow/HvReeLLpyV
gjWIdj1Nc/SfeGD17UOCEpsmuL+6umJmmdvqar9SAMkmrmnWa3TSB1csuMKO9QlP
J1PZ90LKB9OalSV7Ibi7czIpY5ItokQqSMjNXJNNaPTfte5iMAjA45q54ntltrqA
KSQUPJrTuD5vgeM+kY/Q1N20mVZJtFLwxp8V8LhpMZjIxxk1gyjZcyj+65/nXSeC
3/e3ieqqf51zl3xe3A/6aN/OqS95k3vE9SibdDG3qoP6UVDYN5mnWzesS/yoqC1s
dKWIqMuR1OKUmoZOVI9qpEtnHal4/eKR4bSzwykqWlOeR7CuavfFOsX2RJduqH+G
P5RTvFFmbbWZmCkJIfMU49ev61mxR+WAzD5j0Hp71fKrmfM2g2vu3SMWkP8AeOcU
HIoJ565NGfyrRIQlNJpxppoEJR60UelAEttOba5R8/L0au6064DBSO9efsK39Cvs
AQyHkdD6isakep0UZW0O4luPs8BkPpxWTPd3Vwx2kkHsp5NX7e5DhASCuc81Lc+R
OuHVTj2rGx13ZkW2n3CsrBCWznirVzYzsCXzuI4BardvZWajL7ceo6irD2ti64RU
b1Zsk/rSaXc0ijIt7m4syquflHfPatmO7WYDa2TTbeC1ifKxrj6daJ5Yo87MDNQk
inzbkF5ccYrkfEF/tjNujfPJ19l71q6rqSWsLyMckDgZ6muIkle4laaU5dv0HpWt
OF3c5q9XlVluxPWij/CkrqOAM0o60hpRQBPDdSwMGikZG9VOKimZ5pjOTmQnLe9I
DSg0rIdzb8VsJBZSg5BXqKs2jeb4Ldeu1WH61zrsWjCMSUByBnoa6DRxnw5dxEgk
FvyIrNxsi07yK/g58ajOv96L+tYl7xqNyP8Apo3860/Cj7daA/vRsKzdQ41S5H/T
Vv50/tC+yeh6LJv0WzP/AEyAoqloM3/EjtRnopH6mioaKTOyLUxjSE0wtk1QjlPG
YhW1hDn955m5F9Rjn+lcSzZ5Na3iPUDf6xMwbMcZ8tPoO/55rIFaoyFxSEUuKMUw
G0EUppKYDaSnGkI70gEPNWrLLyeUrbZM5jb/AGvT8aq5wfrSglGDA4IOQaTV0NOz
OlstWy4jmGyVThga6CC5jlAy3J6ZrmXjTVLBbhBtu0HUfxY7GoLPU2iZVkJBXg5r
ncTsjU7nbx2xZBsfgmpY7PkGVyARwPSsqz1aEqpEgwB3NTzavEIzlwv41m0dEXHc
u3EqQttDdAKxr/VY4IyGPzA9B3rKvdZyGCNknoap21nJcOJZyWZui/40Rh3JnVvo
ipqM8tyVkkyFY8CqXatHWcLeC3X/AJZKAfqef8Kzq6oKyOCpK8hR0pO9HajvVkBS
jpSHpS9qQBSikpTQAA8+1TQTSQvvjcqSMH3HpUFOBoAu6ADDr8APRtwH5VT1PjVb
r/roasWNwLa9gnZSwjbOBVbUnWTUriRDlWbcD7GotqVfQ6HR7rZpUC56bv8A0I0V
j2c+y1Rc9M/zNFKwrnrBNUdTu/smm3M4PKRkj69BVpmzXN+Mbkw6SkK9ZpAD9Bz/
AIUJalN6HCk888mkzRj1pfrWpmGaAaMUUwDrRSfSjPqKACkIpTRQAzFAOeKWkIwc
jrSA0dIvFtpjHK21H6N2U1rXmlJdHeDskPcdDXMA+tXbXU7qyICSCRMfcY5H/wBa
olG+qNIztoyWTS7uE8LuA7qaYtpdyHAjf8a6DT9RtdRIjz5cx/5Zsev0PetZNPAP
IrN3W5sknscxaaO24NKcn0FbNy8OjWBuJMGZhiFP7zev0FaqwQWsL3EzBY4wWYno
BXA6tqT6pfvOchB8saH+FaIq7Cb5UU3kaSRpHYs7HLE9zQWA9c0gFBIIAHUVscwA
k0vc0gpe9AAeopTSd6DTAUdaCeaOgpM0gFFLmm0oNADs0kkfmLx94dPejNKDQBCj
lVAoqUxoxJIOT6UVNgPXCa5rxkobS4X7rN/MGuhY1g+LBv0Vv9mRT/Sktxy2OEpa
SjNaEi0UZopgGKSlooAQUEUHmjNIBp5/GjqKU0goATFAz7UHrRQMATkf0ro9J8US
W5SC+zJF0En8S/X1H61zmaU9OlJpMcZOLujp/FerrO0djbyBogA8jKeGPYf1rl84
oHoKMUkrIcpOTuxetFFFMkKX0pKUdKAE7ml70h70gPSmA40gopaACiiikAtFJS0A
OzRTaKAPVWasnX036JdeoUMPwIrRJqpqSiTTbpOuYm/lUoGedUUlL1qxBRRRmgAz
S0lGKAFpCM0Z9aM+9ADSaTvTmFN6mgBetJThQRQMbSntRijvSAUCkNKeDSGgAoNA
ooAKBRQKAEJoPWhqbmgB1LTQc04UALRRRTAKKQ0daQC5PpRRxRQB6Yz1G37xGU9G
BFITUU9xHbRGWVwqL1JoEcA6FWZT1UkUzpUtxIJbmWRRgOxYD0yaj6GmAdaKTHPF
L1oAKWiimAYpCKWikAlMIwRTzTH4waQxc4p1MbpSqcigBaKDRQAUlLmkoAKKKKAC
gUUUAI3SmGnt0qM0gHA04Hiox1p2aaAdkUuabn0FKKACj8c0fWjPtQAufaiiigD0
VnVFLOwVQMkk4Arh9T1KW/uWZm/dKSI1HQD1rqNYtpbzTZIYc7yQcD+LnpXFSIY3
ZG6qcGgSFByBS0xT1FOzihDFFBoopiD60tJS0wCiiikAU0jinUhFAxnahe9DDHeh
aQDqTvSjnpSEEdQRQAZyaKKKACiiigBKWkooAD0plPNNCFjSY0myaMqiZ9RUB4PS
pVQjtQ0TN0HNQnZmrjdEYNOqxFp9zL92M49TxV6HQ5WALsF9hTdSK3ZMaU5bIycU
7FdJb6FAMbwWPua0YNJtVxiFc+4rN14rY2WEm9zisUV6CNMgx/q0/wC+aKn6wuxX
1N9zndX1s4MNs/ykYLjv9PaudJyTUkyHcW6j+VQmug4xyn5qfUVSA5ANNAHPalz6
8UUcUxC9elGKTb6UZx1oAWik4NLjFABQc0ta+g6WmozSGTlI8cepNJuyuVGLk7Ip
WWkXWoEGJdqf32/p610Fn4Wt4WU3JaVuu08CujhWG1UQQxhnA57BacsRMhYnLt1N
c0qjZ2woxW+pFFYwxxiOKJIx6KoFPfTlYYdAw91BrSgtowoOWL9zmpWXjFYnUkrH
Mz+HbGfO63UH1Xj+VZs/g6FuYZnX6812e3scGmGPJ4pqUlsxOnTlujgZfCN4mdks
bD3BFVZPDeox9Y1P0avSPLB47mlNurcAc5qvbTMnhqbPMl8P6gTgxAf8Cqwnhq66
vsA+pNehfZF7UhgU9hQ60wWFpnBjw1J0Z/yWpl8OIpHzMc9e1do0AP50wwDv9BUu
pJ9TVUILocqNEiQgFM+uTVqPTUQjCADGeBW2IBtOfpQYl6iobbLUIroZiWgH8PHc
VJ5IB4A61oeWMEg0nlkcVJWhV8nOPSniPI9KsBODnmmBArd+aBiqjbRzRTwpIyCc
UUCuf//ZiQI6BBMBCgAkAhsvBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheABQJR3mUf
AhkBAAoJEM2Ptb2FvwslIX8P/0pfyApnWafZsMWwyQArnr+f+WOSF/PjidchK7rV
PJSLk+ZLraaKLGzUy0dPPnOzR8vhPfeam7Dg7R5heD9SwOzzjEzrESwps7ntkp6K
zCrAEZt8ycVKNtzd+aZJKGBmFv/JMtpQG5ph84VqQt5WUjIK8+KzJkDEX/idOkmG
E8KfslCut8aFKQ5fWz0u29+TxShlvS0lkKAAq8jeM0XHH1kruymTq4iE4lUUzt6u
OJXi0dv4vC6+yuPhXjKmE6Xt0gSSA9WctUjWB3g2i6g996jo7qUQABKPH2MFQS0T
G8fC2EhvS2Z4r7pOOp91UBbRYVyDCg7AyFbOKs6aKbJ+pTGVKdXqmGOt5LkROxmx
ChdvGA9pYWCeX6Enw7eXYDFLxhnzrhJpuMcW8U4LwVrD2hI7LLcxOjT7zXyzMt6B
yCQRECMjcRoKApw3xX32WzW/HmsBvSRVMAQueDtGus3RLJWeutABHsAoa3+TaG7C
DyBWRkLi/O1lLClf40EhfgQEiyBNvVyUs65juVtQzdeyFNGYFLEOIBBAgeg+6g/c
UnVx94Xo+LQ8VThbdymrExOqjxw5gnd0FLx/sHu2oNUC9c7a/NWzo+LHZKx88G6D
Ns1LGb7nYtNPhChfhbkdrwQwQQKCmGKuA3EyuAXaoS8mNNNbfpMD643lSOR+WsgL
CGaEuQINBFHScT0BEADCveJ6u4zw7d+GwAu0V/utB7aifnFNg9iCUN/8cO1qYafB
gj53kWWWAIwjcvhY9BZPCTCtekE7/PCToUUdOdNSJw15/Kie7vKrHMG02womWb61
/xjqAQC50sciCuwvIzqBYM8w5yPDXU532iWNr7Ao4J2GRWb5ebE6NxOUcvZSbAWw
NnyxgVMvZCNTI6ZCvYx8/hTbkwlpUIbZuEAwJgsBoJq8RheHw5puAkHHsx4Sl0/l
oTnKIFWxeZ8UioikeUhkVqeC5OFznWuSnNDHgkVw+l/iPjG0rsF/N9k7bZz9oM1y
y32BiHaW4RFALAuEeRQdj2ULCs1sTc1hd8mKRVhQw3iXDixZJMjKeWPT4B40GvKw
rnUMHOcgpLb+TWBTqLeEI/1VLHt2VijDRj/I/YaSi64HAIk7887ISQRFn+QyoOHW
ph973awD/cOwUJ7NY2/EjO2rJpRxqJm5BGpl41e1Lq6b0zF49+IyPRzomBhuBxq7
dzT8GEeuYFOCvvjsv2xEYKolcEjE+0GpVRAu4Q7mayEFwgEeQt8zs3xRcKT7sfK5
urGiHKq9pJbQCA8NKMVECyWHxBLcXv8oPyVLOoaKsZu5V8Lu/Mb7fPEOHPBPavIF
h7zVjtzv2I+7NoGPJR78YYlxtxCwDAbOBs/O3kuDC5Eo6x1u+CBMyFHRdIplQQAR
AQABiQQ+BBgBCgAJBQJR0nE9AhsuAikJEM2Ptb2FvwslwV0gBBkBCgAGBQJR0nE9
AAoJED2appCQubIj5ScP/iPzND0wcn7Iu5QpzRFwYE9ge9T2WAYRFJG3qjTXbITm
GZ2Oyneb1hPE7m2c6IqOmlTFjhl9PMO80TZsOZpE5lJ21nPqFyEAjPf8oxCcBzFH
EbJGxsUDFjbiT33C1cXUnopB7WLdgCC4JfHWuU2uffIYI5NfSiFYwLLrKbBwxSdw
6RKLocvmtJ+/NwfiJR8Q7ZIL5UZH+C2vWhwOxE5fK+eXGBJQWg7MfzB41DDNTYNQ
JejmR/sACIrz3QEOsZgLNN/2sbjhB7boxWeWf15I2Ervrt2RS9bXbc99zf1kXmNR
+qC+VQIK0acUZnyefCzeMOueThX0iJ7UmttgKP4VJQ1Up3h2KSIqP+KCIyuqvqDA
Ksy5Q4B41eV0+/7xzEY6S7LawmBRs1lqtpXiG91Hgw5VQjIBtfBVfKtU3LCZBHfr
TifhDi4pUtLoLgqPBo8oe80GDQvOV34356ov0DYWDg9rEYx+dI8lgXY7NnC471pQ
wGPzdIfgMMOeExhyVFqR2/yJR+PGwIcLN3WskI9xQbAld7pn1Yyq7LyoJRI6eva8
HwyRmm7h0odDVB0GRrFFgYeDh8XjUy1YvIMpIpZgpGFTZWOOEhjDjgZ2XdpZmfSA
fWiRPnaQnR+jkeCzffnXvzt0u4a3bRLlizjQ4DI31/arF/mxYxLDcdynyHeZzgiL
H64QAJ7rY/RZG1gB3nCfRIY8Rxr8+h5RuuP13ToLmztM7I0a9vMkAjn1qzljBP9I
Jati9Fm3vHNjb2NbR3YpECAz/hg8WRwK+N/hTTcuCg6/cnRP/8YRvIx+nKS9x88I
fpAuogQQyHHV6hjUsObh6TvdagOIrVgPPavvOctW9LoHsJu2MpbcEcmqP+gCJcqT
qBAZIcmL/JXz0q2aY0rSwUJiZ2Q+RGH/mcdRP9QrA6dmG7r6LtJHnC6tI9ppRpoN
m0+BpKhKDJyCzFfcq+/ZF+BkkcOFGk7rJIhU9QahIkerDqI9iUrkC7shnhs5384a
8zpmwTebCmwfKjqgx1iS0ZP00DRXOHa4iW0tW41cAr447XkEXdKd4yGLbtmmry9Q
N3z0eoKknG7Ezywj6RkqU0BGbpTCVER88PaLLvLCxX0aRQWQkw+4/ND0pLD06xCV
wuuH526aAC48zZVv5NioiDmsNu7nrikCPGiiZYKv2ikYxXmqomN6Q+0F49O6xyLE
1cIq7sdPZmk+P34Y/beukbi6HgxQ1koN/sIUPNPfxO6gDXJZbtburJu/PChvwGlE
EisX2+2NEHrE5NMyT0ZRoo+GH1xyxdL6qbB1RzhuPsqM9Kg9gOAlOZc1AZe39Y30
IVQpcyYx2OAqp2rdVRmj9JmQIlYzuC/BFIPiV796COI33Yd/
=2VJ/
-----END PGP PUBLIC KEY BLOCK-----

Wednesday, February 06, 2013

No, this blog is not hosting malware

Sometimes googles malware detection gets a little stupid; and they flag completely benign sites as hosting or distributing malware.

In this case goggle malware detection is reporting that I am hosting or distributing content from "cooking issues" "a known malware distributor".

Well, first of all I'm not hosting or distributing content from them; they are (or were, I just removed it) a link in my blogroll nothing more.

Second, they aren't a known malware distributor, they're the blog of a few instructors at a cooking school who like to mess around with unusual and interesting techniques for producing food. Very good site, I just wish they'd update more often.

It appears they haven't updated since August... and it's entirely possible that in that time someone has snuck some malware onto their site... But much more likely is that they also have a link to a site, which has a link to a site etc... etc...

This is the weakness of automated malware detection, automated intrusion detection etc... In fact, this can even be used as a deliberate denial of service attack, getting "content protection" services to block a site (it can be VERY difficult and annoying to get unblocked).

Anyway, I've pulled the link off my blogroll and everything seems to be fine now, with no more false alarms.

Sunday, July 29, 2012

Commie Fuckwits "infiltrate" Y-12, somehow don't get brains blown out

http://www.knoxnews.com/news/2012/jul/2 ... rity-zone/

OAK RIDGE — Three peace activists — including an 82-year-old nun — infiltrated the highest-security area of the Y-12 nuclear weapons plant in a predawn protest today, reportedly evading guards and cutting through three or four fences in order to spray-paint messages, hang banners and pour human blood at the site where warhead parts are manufactured and the nation's stockpile of bomb-grade uranium is stored.

And for those of you who DON'T know what Y-12 is... let's just say as bad as the news reports this is, it isn't even close.

This isn't a matter of people being fired... it's a matter of people never getting out of prison again.

The group they're from, "Plowshares", is a communist front group, has been for... 45 years I think?

I just love this line:

Steven Wyatt, a spokesman for the National Nuclear Security Administration at Y-12, declined to discuss details of the early-morning events at the Oak Ridge, but he acknowledged that the unapproved entry into the plant's inner sanctum — a high-security zone known simply as the Protected Area — is unprecedented.

"There's never been a situation like this before to my knowledge," Wyatt said Saturday afternoon.

If unarmed protesters dressed in dark clothing could reach the plant's core during the cover of dark, it raised questions about the plant's security against more menacing intruders.

"I'm sure we'll learn from this, without question, and use what we learn to improve security," Wyatt said.

Ya fucking think so Skippy?

This is going to come out that it was about the 35 guards being let go, I guarantee it. There is NO way these idiots got where they did without somebody looking the other way... Confirmed by the fact that the geniuses didn't manage to get shot in the process.

HT: Insty

Thursday, July 12, 2012

A little tip for everyone with corporate voicemail

Here's a piece of entirely unsolicited, but very well informed, information security advice.

If you have a corporate voicemail system, go and change your voicemail passwords, today, to the most secure password the system will allow (that you can remember easily enough); then delete any voicemails you have with private information on them.

Oh and don't make your vmail passwd or pin the same as any other passwd or pin. Really, do NOT do that.

Then do it again at least every week for the next... oh, call it six weeks... maybe two months... And check and delete your voicemails every few hours, or at least once a day.

Trust me on this one.

There's a very good chance you'll be receiving an email telling you to do this from your corporate voicemail manager in the next few weeks.

Thursday, July 05, 2012

Many are aware of...

... the "old" proverb "do not meddle in the affairs of wizards, for they are subtle, and quick to anger".

Some few also know the vairant thereof "do not meddle in the affairs of dragons, for you are crunchy, and taste good ketchup".

Apparently, someone at DHS forgot the engineers corollary to this proverb:

"Do not irritate an engineer, for smiting you will amuse them, and make a good story over beer"

Friday, June 08, 2012

Frustration...

Management: "Users are having massive problems"

Security: "okay, lets figure out why"

Figures out four separate things that are DEFINITELY causing problems, reports these four separate things.

Management: "So it's this one problem then"

Security AND Applications AND Desktop: "no, it's these four interrelated problems, and it only becomes visible when three of them are present."

Management: "OK, so it's this other problem then, we should remove that software"

Everyone Else: "No, it's not this other problem and removing the software isn't the solution. We HAVE a solution for this other problem"

Management: "Ok well... lets do what I said anyway"

Security: "That doesn't solve the real problem"

Management: "I don't beleve there is a "real" problem... it's just these things we have an easy solution for"

PROVES, beyond reasonable or unreasonable doubt, that there IS a real problem, that we know what it is, how to detect it, and how we have to deal with it.

Management: "Ok... I believe you... how do we fix it"

Security: "This is how we fix it. it is difficult and painful and will only MOSTLY fix the problem"

Management: "We can't do that"

Security: "Then we will keep having the problem"

Management: "So tell me what we can do to fix the problem"

Security: "I did... there isn't anything else we can do to fix the problem"

Management: "I don't believe you, get an outside expert"

Gets outside expert

Outside expert says the problem is the EXACT SAME THING as Security said.

Management: "So how do we fix it"

Outside expert says the EXACT SAME THING as Security said.

Security refrains from saying "I told you so", and instead says: "So, this is the problem, these are the issues it's related to, this is who it's impacting, this is how and why, these are the risks, these are the seven things we can do that can help it, this is the user impact of that, and this is the cost".

Management:"We can't do that... and you absolutely cannot say that in front of MANGEMENTS MANAGEMENT... I don't believe you, we aren't really having the problem you say we're having"

PROVES the problem AGAIN, with even more evidence

Lather, rinse, repeat

That has been my last three weeks

UPDATE:

I should note, that this is a gross oversimplification; and that "Management" in this case isn't actually senior management, and it isn't everyone... it's some of the managers and leads of some of the other groups we interface with.

Over the past few weeks, I have had to prove, over and over again, that I know what I'm talking about, that it really is a problem, and that we really do need to fix it.. and I've explained at least a dozen times now the nature of the problem, and what our mitigation options are.

By the time I wrote this last Friday I was pretty damned irritated, and EXTREMELY frustrated and tired. I have been working 10-12 hour days plus 3 hours of commute, every day for more than three weeks, having to prove everything I say, every step along the way, for every new person that got involved etc... etc...

By Friday, I had pretty much had it up to... wherever...

I actually ended up raising my voice in frustration earlier in the day (I apologized right after) with someone who was being particularly obstinate in insisting that I was wrong, and that my proof was invalid.

I don't even know what sr. management has been told at this point. I'm pretty sure that if they get good information to make a decision from, they'll make a good decision... it's getting there that has been the problem.

Thursday, May 10, 2012

10 hours at work, 3 hours on the road... long damn day

I spent 9 hours today dealing with distributed botnet scans, floods, and relay attacks.

For those of us who are infosec professionals, and server or network admins; you all know how irritating, frustrating, and nearly futile that can be.

You can mitigate, and remediate, but not resolve.

Blocking subnets is only a partial solution. It doesn't work for very long, because the very nature of a distributed attack is such that it will simply shift to other subnets; and of course the same applys to blocking hosts.

And of course, that doesn't solve the problem of link saturation. You need to get your upstream provider to filter the traffic at their end... and you still have the same problem with shifting attack sources.

Oh and of course, when you blackhole entire netblocks, legitimate things sometimes break.

One lovely trick loved by botnetters is to compromise a host with a content distribution network front end (like Akamai), and using that to spread their attacks even further, hiding them in the legitimate traffic and making it effectively unblockable, unless you're willing to break a quarter of the entire internet into your site.

You can really go down a hole chasing this stuff down and trying to flyswat it.

I go fall down now.

Tuesday, June 07, 2011

For everyone expecting me to comment in detail on the SecureID thing...

I can't.

I am a senior technology executive at a large financial institution, who is a customer of RSA (EVERY large financial institution is a customer of RSA. I mean that literally. I don't know of anyone in this business that DOESN'T use SecureID). I also have what might be construed as inside knowledge, because of friends still working with RSA and their direct partners. 

I can't make definitive or specific public statements.

There are a couple things I can say.

First, this is someone not speaking for my company, nor relating anything that has happened at my company,  or to my direct personal knowledge any other company excepting those already admitted and released publicly. 

I am speaking as a security expert who knows the market and the players very well; as well as a certified RSA SecureID Administrator, Systems Engineer, and a certified instructor (though my certs have expired, the technology hasn't changed); who has taught thousands of other SecureID admins and engineers. 

This compromise is bad. It's very very bad. It's worse than you think it is from reading the already quite bad (though spun so hard it created its own gravity) admission and letter to RSA customers.

It's as bad as I thought it might be in the post I wrote about the breech at RSA a few months back. 

If you remember, the title of that post was "Oh SHIT! Really just doesn't cover it".

Also, and this is entirely speculation on my part, thought it is informed speculation based on what I know of some of the large contracts RSA has...

The compromise is bad enough...

...BUT...

Their response to the compromise, combined with indemnification agreements, and contract requirements in place with some very large customers...

Well, if I were a lawyer working for some of these companies (and municipalities, and federal governments for that matter) I would already be filing a lawsuit claiming malfeasance and breach of contract on the part of RSA.

It's very clear to me, simply from publicly available information (and to any other expert on the technology) that RSA could have, and should have, foreseen the reasonable possibility of actual injury, and acted accordingly to protect their customer base. From what information is available today, it appears they did not.

In addition to the actual cost of addressing the breach, which could climb into the 2 billion range; the claims of tortius injury could run into the tens of billions.

This may very well put RSA out of business permanently. I'm not sure of the exact structure of the company, but if RSA does go down, it could even take down their parent company EMC (RSA is not a separate operating company or wholly owned subsidiary of EMC, it is a semi-autonomous organic division of the company. There may be no legal firewall between them).






Thursday, March 17, 2011

The words "Oh SHIT", really just don't cover it...

Uhhh... this is double plus ungood:

"RSA, the security division of Hopkinton-based EMC Corp., issued an “urgent message” to customers that its systems were hit by “an extremely sophisticated cyber attack.”

The message from RSA Executive Chairman Arthur Coviello was posted this afternoon on the company’s Web site and disclosed by EMC in a filing with the U.S. Securities and Exchange Commission.

“We took a variety of aggressive measures against the threat to protect our business and our customers, including further hardening of our IT infrastructure,” Coviello wrote. “We also immediately began an extensive investigation of the attack and are working closely with the appropriate authorities.”

He added that the hack “resulted in certain information being extracted” from RSA’s systems, relating to the company’s SecurID “two-factor authentication” products, which businesses and governments use to protect sensitive data on their computer networks.

“While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack,” Coviello said. “We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations.”
And then this...

http://securosis.com/blog/rsa-breached-secureid-affected

You've gotta understand, SecureID is THE authentication solution for probably 80% of all high security remote access systems out there.

If SecureID is compromised, even in a way that's technically easy to fix (like replacing keys, which can be sent out via a physical media patch; but for security reasons can't be distributed electronically), you're talking about literally hundreds of thousands of man hours to fix it, plus the couple of days of vulnerability before the media can be shipped and the keys can be updated, plus all the lost work hours and productivity fixing and debugging the access issues that are sure to show up.

Many companies (including mine... and almost every other company I know of for that matter), depend on SecureID for remote access, which is how a large percentage of their workforces get their jobs done.

I literally could not work without my SecureID token working; and it would take weeks to get an alternate solution in place, other than having to piggyback a terminal in a local office.

Any kind of systemic SecureID hiccup is a HUGE deal. Even minor problems in one company can often cost that company millions of dollars in lost productivity.

If it's a worse compromise than that... if for example, it requires a trade in of all SecureID authentication devices... and that's millions (I've got one, and I'd wager a large fraction of my readers do too), the issue could take months to resolve. The cost, loss of productivity, and loss of reputation, may put the RSA division of EMC out of business.

And of course, those are the BEST case scenarios...

While it would be nice to think that every organization security minded enough to use SecureID, would be secure minded enough to keep up with security patching and compromises, and would have a procedure in place to disable remote access... Reality says otherwise. There would likely be thousands and thousands of organizations running vulnerable for months, or even "forever". That could be billions in damage, lost privacy... tens of billions...

Let's hope the nature and extent of the compromise can be ABSOLUTELY PROVEN (to a standard of audit-ability by the NSA, which is even harder than you think it is), to be minor, non systemic, and present no end user risk. Otherwise, this is a Chinese fire drill of epic proportions.

Tuesday, November 02, 2010

In which I get irritated, and show someone what "Expert" REALLY means

Now, I think all my regular readers know, I am without any reservation, an expert on both mobile telecommunications, and on information security. I have both extensive knowledge, and extensive experience in both fields; and frankly this should be obvious by even a cursory reading of any one of my postings on the subject.

Normally, I just use the verbal shortcut "I do this for a living", and that gets the point across... but sometimes, not so much.

So, on another site, someone asked for useful comparisons between the iPhone, and the Blackberry. As I am intimately familiar with both, I decided to chime in; and included a bit of data about Android in the process.

So, here goes:
"I have all three of the major smartphone platform devices (all others are now obsolete if not orphaned - sorry palm, nokia, sony-ericsson et al), a blackberry being required for work, and having switched from iPhone 3gs to Android (DroidX) a few months ago.

The iPhone (platform) is a computer with a smoothed and simplified interface, no hardware keyboard, and a locked down software base, that happens to make phone calls.

The Blackberry (platform) is an email appliance, with a not particularly smoothed and simplified interface, generally a hardware keyboard, and a locked down software base, that happens to make phone calls.

The Android (platform) is a computer, with a reasonably well smoothed but not particularly simplified interface, which is nearly completely customizable, can have either a hardware or software keyboard, has a wide open software base, and happens to make phone calls.

Of the three, the iPhone is the "best done"; as in the smoothest implementation, the cleanest hardware integration etc... It's also the most expensive by far, and the most limited in options... though the huge application base does in part make up for it.

The Android is slightly less "well done", but is improving constantly, has near infinite options, and the application base is growing rapidly.

The blackberry platform will be dead in three years. It is the most limited in functionality, it has serious security problems, it has serious privacy issues; and the one and ONLY thing it does very well, email, can actually be done just as well if not better by the others. The only thing keeping Blackberry alive right now is the large corporate install base, and they are largely looking at the next tech refresh period and looking to integrate Android and iPhone.

My company, one of the largest and most conservative in the world, and one of the largest blackberry customers (over 100,000 blackberries in our various organizations and divisions) has already certified iOs and its enterprise exchange connector, and already offers iPhones. I just can't have on in my area because AT&T's network is crap here. They also offer support the iPhone vpn connection. They are in the midst of validating and certifying the VPN connection and exchange connector over VPN for Android.

I know that pretty much every other company in our sector is doing the same thing, as are many former clients in healthcare and medical, finance and insurance, and technology.

The only big organizational customer not looking to dump blackberry right now is the fedgov, and that's because they have a "special relationship" with RIM regarding security.

Guess what? They also have that same relationship with Microsoft, and there is a trusted secure version of Windows Phone 7 on the way (as it happens, a good friend of mine is a senior developer in the WinPhone7 devteam. I'll have to pick his brain on that). From what I have heard from inside GD though, the next secure mobile telephone unit from General Dynamics, will be running WinPhone7.

Best bet? RIM gets acquired by someone looking to make a play in enterprise messaging (Cisco? MS?) and becomes a software and backend company, offering groupware sync from cloud to mobile and back to desktop. 
WinPhone 7.... ask me in a year. "
So, pretty straightforward right? Nothing particularly earth shattering, or for that matter insultworthy right?

Well, apparently there was....
@IncorrectUser1 "@AnarchAngel, You're wrong about Blackberry. It's the ONLY device that offers full security for the end user."
@IncorrectUser2 "AnarchAngel wow are you uninformed to say the least. RIM and their Blackberry devices are VERY secure, they are highly encrypted and provide great security for their end users. RIM recently risked getting banned in India and the UAE because of the encryption and security they had on their devices because it wouldn't allow the government to spy on their users. Apple and the iPhone don't have this kind of thing. As for Microsoft, they hand over every way they know of to let the government to spy on the users of their software, with little more than a kind word.

As for the security issues with RIM and the Blackberry, they pale in comparison to the iPhone, it gets jailbroken, aka hacked, within days of releasing the new version. I won't even start with the amount of security issues that Microsoft has, however XP was certified with the "you showed up and turned on the computer" security level by the NSA when it went in for test. Blackberry's Unix got rate higher than that."
Whoa boy.... he don't know who he's talking to, now does he....

This is the part where I get tired of half  "experts", and let my inner asshole free for a minute...
"Norrmally I hate this, because it degenerates into pointless shouting, but f**k it, let's play.
Before you call someone uninformed, because they disagree with your marginally informed opinion, you should know who it is you are dealing with.
I'm chief infrastructure architect for the retail, credit card, and internet banking division (yes, they're all one division) of a major bank; and was a security architect and consultant for years before that.
My work as a consultant, included work in information and communications security for Lockheed Martin mission systems, and General Dynamics.
If you know anything at all about security, especially about security in mobile communications, you will understand the significance of that. 
I was also an intelligence officer in the USAF(R). My last two years in the reserves were spent in communications security. In fact, that's primarily how I got the contracts with Mission Systems and GD to begin with. If you happen to know anyone in that world (which I rather doubt), I could give you contacts to verify.
I am being somewhat vague here, because of security considerations, both from a clearance standpoint, and from a professional responsibilities and ethics standpoint; and of course because of NDAs.
Now, if you want to start arguing security credentials, great: I'm a CISSP, and CCIE (security). I'm a certified systems engineer/expert and Instructor for Checkpoint, Nokia, Netscreen, Sonicwall, RSA (SecureID), McAffee, Symantec, and ISS. I am certified as a security engineer and to give instruction on security in Windows Server (up through 2003. I didn't bother recertifying for 2008), Redhat Enterprise Linux, Solaris, HPUX, and AIX.
I should say, I WAS all of those things. Some of those certs have expired, or were dependent on working for a certified training partner (as my information security consultancies were, for various vendors, as were the consulting practices I worked for). I honestly don't keep track. In IT one collects certifications all over the place, and generally you only maintain them if someone else is paying, or they are critical for the job you are doing.
As a consultant and professional trainer, I have trained thousands of other engineers and architects on the principles of information security, on how to evaluate information security, and on the specifics of implementing security technologies in their environments.
I have two published textbooks (co-author) on information security, as well as dozens of published articles in industry publications.
I co-founded and acted as chief technical officer for two different independent security consultancies.
I was the senior security architect and senior consultant for three other nationally and internationally known consulting practices.
I am one of the co-founders of the Linux advocacy council, and a former chair of its security subcouncil. I was a frequent presenter before the Irish Information Security Forum (IISF), including presenting one of the keynotes at the first general meeting in 2001; and the European Information Security Forum; as well as a presenter or co-presenter on information security topics at SAGE, USENIX, Defcon, and several other industry events, multiple times.
I, as chief architect for one of the partners in a technology alliance, along with security engineers and architects for Hitachi, EMC, Brocade, and Juniper; co developed, and assigned as developers, patents on a number of security technologies relating to secure multiuser SAN environments, SAN switching security, secure distributed SANs and SAN firewalling.
If you have any idea who works in security, we can talk about the people I know, and who knows me...
Oh and just coincidentally, I happen to know the delivery manager for the next generation Sectera mobile Secure Telephone Unit from General Dynamics. As it happens, she's engaged to my best friend. They're supposed to be married in April, but I think they're changing the date again. She works out of the facility on McDowell in Scottsdale. Great lady. Third generation Mexican American, but she talks like a California girl. 
... but frankly, I really don't need to do any more dick waving. If you know anything about information security, or have worked in the field, you probably already know who I am. If not, it would be meaningless to you anyway.
But, let's just get this clear.... I am almost certainly better informed, more knowledgeable, and have more experience in this subject, than you.
Now, having taught someone what "Expert" REALLY means, I get down to destroying their misinformed points.
I know all about Blackberry and RIMs security; both in the commercial and government context.
For one thing, I know that the NSA, DIA, CIA-S&T, and DISA have both been working with RIM and simultaneously trying to get rid of them in government service BECAUSE OF SECURITY CONCERNS, for years. I have worked on several associated projects and contracts.
Why the hell do you think they made Obama stop using the blackberry for presidential business. It's certainly not because it was "too secure" and the NSA wanted him to use something less secure. There is a REASON they made him move to the GD Sectera mobile STU.
Why do you think JSOC just put out the order to switch to Android phones and iPhones, with a newly developed set of security tools; and are migrating their enterprise connectors away from BlackBerry Internet service and Blackberry Enterprise Server, and to Android and iPhone enterprise connectors as soon as they can (last I heard they estimated it would take two years).
Thanks to NDAs, I know a hell of a lot more than I WANT to know about RIM and Blackberry "security".
Now, the difference between Blackberry, and the iPhone and Android systems, is that Blackberry pretends to be secure, and assumes a trusted third party. Neither Apple, nor Android do.
If you are using Apple or Android in an enterprise messaging application, you encrypt all the traffic end to end, with encryption that you manage, using industry standard protocols. At no time in flight is any communication un-encapsulated or decrypted, and at no time does un-encapsulated cleartext pass through any systems controlled by either Apple or Google (though like all encapsulation systems, endpoint analysis and volume analysis are possible for elements of traffic analysis).
All three operating systems have exploits. Most of them are zeroday rooted with every update and revision. The point is, DON'T TRUST THE PLATFORM, and most certainly don't trust any third party.
No system that requires a third party controlled messaging server can be guaranteed to be secure or private.
No system that requires proprietary protocol use, managed and controlled in an unaudited code base by a third party in a remote location, can be guaranteed to be secure or private.
No service that depends on the good auspices of a third party to function (excepting public key services with a trusted certificate authority), or that requires third party management access (in the case of enterprise, onsite, organizational, or nationally controlled blackberry servers for example) is reliable or highly available, in the context of high security.
That is how BES and BIS function, therefore no system depending on BES and BIS can be said to be secure.
The three elements of security are Confidentiality, Integrity, and Availability. With Blackberry, you can't guarantee any of the three, not because of the base technology, but because their system architecture builds in this weakness explicitly.
There is a REASON why, repressive governments allow Blackberries. It's because RIM build holes in BES, and BIS, to allow those governments to spy on blackberry users within their countries (to varying degrees. RIM has proven very willing to work with governments). They allow the NSA and the FBI to spy on users in the US and Canada, BY FEDERAL LAW in both nations; as well as by consent decree.
They don't disclose this publicly in plain language, but it's not exactly a secret either. It's easy enough to understand when you read what they DO say.
No, Blackberry email services and blackberry messenger are NOT secure; with regard to governments.
They are regarded as secure commercially, only because any company that could prove a breach by RIM would sue them into oblivion; and for commercial purposes that is considered adequate.
Apple and Android have their own security issues; but they are host based, and can be addresses at the host level, rather than an inherent weakness based on infrastructure architecture.
... Or at least no weakness every other device that depends on the TCP/IP stack doesn't also have anyway.

And that folks, is what Expert REALLY means.

Friday, June 25, 2010

I'm not sure how often I can say this...

Or how much I can ephasize it... I've been delivering this message in every privacy and security training class I've delivered for over 10 years....


Never put private information, or send communications over the internet, unless it is in a secure, encrypted, controlled, and verified way; and in all steps of the end to end chain from senders eyeball to receivers eyeball, it stays that way. note: If you actually want email privacy, I recommend PGP for starters. 

Email, is almost exactly the opposite of that. The only way email could be any less private is if it automatically remailed itself out to hundreds of people, who might then forward it on to others.

I must have delivered this line 10,000 times by now... Never put anything in an email you wouldn't want published on the front page of the Washington Post....