Category Archives: CI/CD

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 (https://aws.amazon.com/security/penetration-testing/).  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.

Getting MEAN: A Java Developer’s Perspective

I intimidate many people because I’m so pretty. Others might say I’m pretty ugly. But when I had the chance to get MEAN too, I jumped at it. In this context, MEAN is an acronym for the technology stack consisting of: MongoDB, Express, AngularJS and NodeJS. I wanted to briefly document some of my recent experiences and take-aways in working with this technology stack, so here are my thoughts.

For most of my programming career now, I’ve been working with mostly Enterprise Java. I started teaching myself Java in the mid-nineties from an O’Reilly book and from the start found the language very intuitive to understand (then). For a number of years now, however, I’ve been thinking that full-stack JavaScript is the way to go for Enterprise Software Development (and other applications as well). So when I had the opportunity to work on a short project using MEAN I was quite glad to get some hands-on experience with it.

First of all, when working with MEAN, you are essentially using the JavaScript language at all layers of application development, from the front-end to the middle-tier to the back-end data store. Theoretically, this should make the learning curve considerably smaller when working across layers, and should also make JavaScript Developers equally interchangeable across layers. The reality, however, is not quite that, but it’s close.

‘M’ Is For MongoDB

MongoDB is a NoSQL database used for storing JSON Documents. MongoDB is very easy to install and run, especially on Linux-based systems. You can run JavaScript in the database; you can even write MapReduce programs in JavaScript and run them on the database. But the main advantage of using MongoDB in this technology stack is the ability to easily store and retrieve JSON documents without have to apply JSON structure to your data after pulling it out of the database. This makes it easier to ship JSON formatted data directly to your front-end without having to mess with RDBMS tables and SQL… and even DBA’s for that matter (‘…can you PLEASE create a table for me!’). Wait, I don’t say ‘please’ anymore because I’m MEAN.

‘E’ Is For Express

Express is a dream to work with. It’s very simple and intuitive to use and takes no time at all to go from knowing nothing to creating fairly complex JSON REST Web Services. We connected Express to our MongoDB instance using Mongoose, which is so simple even I could configure it. Simple is good, right?

‘A’ Is For AngularJS

I found working in Angular 1.x fairly difficult to understand. The associated documentation is not all that well written and generally not very helpful. I feel like the framework is a bit over-engineered. I have not worked with Angular 2.x yet, so perhaps things have improved. Nevertheless, many, many organizations have invested heavily in Angular, so I’m sure I must be missing something, and without a doubt AngularJS is better than working with Java Server Faces (JSF) or Struts. Nevertheless, I might actually try ReactJS as the front-end framework next time as several co-workers have strongly recommended it.

‘N’ Is For NodeJS

NodeJS is the server-side JavaScript middleware that ran our Express JSON REST Services. Working with NodeJS requires that you get used to writing asynchronous code, but once you get the hang of that it’s quite fun and easy to use. From a Java Developer’s perspective, working with NodeJS is so much more efficient than having to compile and package Java Code into a WAR or EAR before deploying it to a JEE Container, like Tomcat or JBoss or Websphere or Weblogic. In Java land, that process seems to take years sometimes. When using NodeJS and a code monitor like nodemon, you simply forget about about the code deploy process and start to take for granted that your code changes are instantly available for testing on your local server. What?!?!

The Node Package Manager (npm) makes installing and managing modules very easy as well.

Fast Development, Fast Deployment

As mentioned, using code watch tools like nodemon, or even grunt or gulp serve-up local code changes in real-time. That speeds up development time significantly. Moreover, your mocha, chai, karma, etc. test scripts are invoked automatically each time you make a code change, so feedback on whether your build is broken or not is instant and continuous. Once integrated with an efficient Continuous Integration/Continuous Delivery (CI/CD) Pipeline, code commits to Git can be automatically built, tested and pushed-out to a running server in your environment of choice. Of course you can do the same in Java, but I bet that MEAN Developers can develop twice the functionality, if not more, than Java Developers in the same amount of time.

In business, speed kills when your MEAN (and pretty).