Category Archives: Computer Security

Barbarians Inside the Gates: AWS Security Roadshow

AWS Security Roadshow, Tysons Corner, VA (5/23/2017)

I attended the AWS Security Roadshow yesterday in Tysons Corner, VA (5/23/2017).  Members of the AWS Technical Services Team delivered various briefings and answered one-on-questions regarding best practices for securing one’s AWS Cloud-Based Software Solutions.  One of my biggest take-a-ways was the idea of ‘DevSecOps’.

The software development life cycle (SDLC) is typically a process balanced by two competing forces: Development and Operational Staff.  The Development Staff is typically motivated by the imperative to deliver quality code quickly and often, while the Operations Staff is typically motivated by the imperative to keep the Production Environment running and stable, with as few changes as possible.  AWS are encouraging users of their platform to include a third competing component in the typical SDLC: Security Staff.

Security Staff, the ‘Sec’ in the term ‘DevSecOps’, are motivated by the imperative to keep the bad guys away from Enterprise Data, promising to make the balancing act between Development and Operational imperatives even more contentious, albeit a necessary contention at that.  Security Engineers need to be integral components of any Enterprise Software Engineer Team, and they need to be driving Security concerns and architectural decisions from the very beginning of the SDLC.  Computer Security is not a quality gate, but an integral part of the SDLC.

Security Inconsistencies

While overall I am impressed by AWS’ focus on Cloud Security, and their desire to ensure that AWS customers practice ‘Safe OpSec’ (Safe Operational Security, for you AFN Fans) on their platform, I have noticed a few inconsistencies in the overall security messaging:

Practicing Safe OpSec Costs More

Keeping technical assets secure in the AWS Cloud costs more.  For example, if you want to keep your Lambda function safe from the wily internet behind a Virtual Public Cloud (VPC), the VPC is going to cost you.  Moreover, if your Lambda function, running safely on your VPC subnet, needs to access the public network for anything, like to access SES to send out an email notification, your VPC will need to be attached to a NAT to forward internet bound requests out through an Internet Gateway.  The NAT/Gateway implementation is also going to cost you.  So, in reality (and this may matter quite a bit to bootstrapped startups using AWS), it will cost a customer significantly more to secure their cloud-based solution than not.

Even Ehrlich Bachman and his ‘See Food’ startup express angst over AWS charges…

Penetration Testing Can Get You In Trouble

The AWS Staff encouraged participants at this particular Road Show gathering to automate security testing, and penetration testing in particular, into the CI/CD code build and deployment pipeline.  However, penetration testing, in someone else’s cloud infrastructure, can land you in hot water.  You need to be sure to read the law of the land on this issue, and request permission to pen-test from AWS (  From a newbie customer’s perspective, these instructions seem a bit ominous and could deter folks from even bothering.

Alexa Skill Security

I asked one AWS Engineer some questions about Alexa Security and how Alexa might be securely utilized in the Enterprise.  The engineer I asked was not an Alexa engineer, so agreed to forward my question to the Alexa Engineering Staff.  I have not heard anything back yet on my questions, but I suspect IT security and Alexa Skills have yet to meet one another.

Think Like A Barbarian

I am impressed that AWS is concerned enough about sharing security concerns with their customers that they are traveling around the United States to help ensure that IT security remains a primary concern.  AWS have a vested interest in customers who are well educated on AWS Cloud services and security best practices.  Their message is clear: when deploying applications to the AWS infrastructure, think like a Black Hat and use AWS services and best practices to help protect your assets.  As more and more organizations move to AWS, IT Security becomes increasingly important for the growing universe of AWS Cloud Customers.

'Out of the Box' Rubik

‘Out of the Box’: Your COTS Products Are Not Secure

Somewhere, a CIO has just spent millions of dollars on new software licenses for new JEE Application Servers.  The DevOps Team hurriedly installs the software, probably feeling crunched by a time deadline.  The Software Development Teams hurriedly deploy custom software on top of the newly acquired JEE Container, also pressured by similar time deadlines.  All the while, no one has considered the default configuration settings for the new JEE Application Server; many don’t think they even matter.  To the contrary, however, Default Application Server Configurations are rarely what your organization wants or needs, especially when it comes to Performance Tuning and Security.  Here is one anecdote to help highlight why relying on Commercial Off The Shelf (COTS) Software, ‘Out of the Box’ and with default settings, is a usually a bad idea.

Take IBM’s Websphere 7, for example.  With a few simple mouse clicks after installing the software in your Enterprise Environment, the DevOps Team can greatly enhance the security profile of your JEE Application Server when implementing SSL/TLS.

As the SSL suite of protocols age, it is becoming a best-practice to solely implement TLS.  For example, many places will want to avoid vulnerabilities to the SSLv3 POODLE attack.

The default configuration for Websphere 7 is to allow both SSL and TLS in-bound (and out-bound) in terms of HTTPS secure channel negotiations.

Websphere 7 SSL and TLS
Websphere 7 SSL and TLS allowed by default.

You could use the configuration screen above to select either all TLS protocols or only the TLS protocol you want to allow.  But this may provide a false sense of security.  The screen above will only prevent in-bound SSL protocol exchanges for external clients trying to connect to your server.  But what if some of the Software Engineers in your organization have written Java HTTPS Client Code, which establishes HTTPS connections with external SOAP or REST Web Services, for example?  Will this code be similarly prevented from using SSL in out-bound HTTPS requests?  The answer is no.

Given the current Websphere 7 configuration above, custom Java code running in your container will still be allowed to negotiate HTTPS connections using SSL for out-bound requests.  If the external Web Service allows SSL, for example, the connection can be successfully established, even if SSLv3 is being used under the covers, from the custom Java code running in your Application Server.

One easy way to lock-down both in-bound and out-bound HTTPS secure channel negotiations to TLS is to simply enable FIPS 140-2 in the Websphere 7 Administrative Console.

Enable FIPS 140-2 in Websphere 7
Enable FIPS 140-2 in Websphere 7.  The default setting is ‘Disable FIPS’.

By simply enabling FIPS 140-2 in Websphere 7, you can effectively limit all in-bound and out-bound HTTPS secure channel negotiations to TLS.  Attempts by custom Java Client Code to use SSL will fail when run inside of the Application Server with FIPS 140-2 enabled.  This will also help you ensure that you have the proper Ciphers enabled and limited as they should be (installing the proper Ciphers is another aspect in the proper configuration of an out-of-the-box Application Server installation).

When it comes to the Security of your JEE Application Server, paying attention to default configuration settings (and changing them as necessary), can yield significant dividends in protecting the data flowing through your systems.  Common sense should prevail in grokking why this is important.




Email Encryption Made Easy(er)

Dear Internet User,

You need to encrypt your sh*&^! There is no excuse to have your personal information, ideas, or other personal communications intercepted and read by prying eyes – such as Google, the NSA or anyone else for that matter. I have had my personal data stolen on at least two occasions so far, because third-party contractors, health care providers, etc do not take information security seriously; moreover, they are all pretty much clueless – and the U.S. Government does not care a lick if your personal information is not secure. But that does not mean you have to be apathetic and clueless too! Start by encrypting your email. It is fairly straight-forward, but it requires at least one friend or family member to be on board with encrypting email.

In general, here are some steps you can follow to get set up to encrypt your email communications so that it becomes too expensive for the US Government, Google, Yahoo or other organizations with a vested interest in seeing what you send over the internet, from being able to do so:

  1. Download and install GNU Privacy Guard. There are Windows, Mac OSX, and Linux installations so it’s easy no matter the platform.
  2. Download and install Thunderbird, the email reader from the Mozilla Foundation.
  3. Install the Enigmail Thunderbird Plugin, which will make it easy to encrypt and decrypt email messages.
  4. The Enigmail plugin will walk you through generating your Public and Private PGP Keys. You will need to export and share your Public PGP Key with friends and family you wish to send encrypted email to.

Once you get all set up, feel free to test your setup with me. You can send me your Public PGP Key and we can test sending and decrypting email messages so you can get the hang of it. Our freedom depends on our ablilities to hide personal information from unintended audiences.

My Public PGP Key: click this link and import my Public PGP Key into your Keyring.