Cloud Security.. at AWS

A few of thAs I said in one of my posts last week, I think that Security should be at the forefront of any good Enterprise Architecture.

Looking at Tips on Cloud Security which focuses on the Core Requirements for an AWS Security Strategy, I think a few of them go way beyond just AWS.

#1) Account Management:  This should be a no brainer, but I've seen it fail.  I've seen employees that have long since been gone still have active accounts, even some of them with elevated privileges.  Sadly there are ways to guard against things like this happening even beyond just setting HR style policies.  Every system I have ever seen has a way to automatically lock accounts from inactivity.  That only protects you really from honest employees, but it's something.
  Another item I've seen where this fails miserably is with "other services".  Like WiFi passwords.  I recently went back to a previous employers location to lend them a hand with some work that I'd done.  Obviously I'd left on good terms.  I fixed their problem, helped them with a few things, and got dinner and a few beers.  Win-Win as far as I was concerned.  My point is that when I got there, my phone automatically synced and connected to their WiFi.  The password was the same from over a year ago.

#4 Identity and Access Management Policies:  I.E. Who can see what.  This is actually a lot harder than is sounds.  The key take-away is always least privilege.

#5 Event Logging and Alerting:  ALERTING is always the hard one.  We all log.  But do we log enough?  And how do you alert off the logs?  This requires some forethought and usually yet another piece of software.  Alerting to downed services and such is easy.  But account logins or hacking attempts is usually a little bit more difficult.

All of these are excellent topics on security and tie in to Application Architecture but can make or break it in execution.

Pizza as a Service

In my job I spend a lot of time dealing with people that are not IT.  Most of the stakeholders are military war fighters.  That's their forte and I'm thankful that there are people that can and do that job.  They come to my command with a good basis of IT skills usually as well as a good understanding of how our exercises run and the direction they need to be taken.  Eventually the topics start to run deeper into more IT-centric stuff.  Especially now as we are trying to move the legacy software packages to..  wait for it...  THE CLOUD!  Oh yes, that wonderful buzz word!  We would like to move as many of our applications to THE CLOUD because the vast majority of our exercises span multiple sites (and even countries).  In the discussions we always end up talking about PaaS, or Iaas, or Saas (or actually MSaaS which is Modeling and Simulation as a Service).  It can get a little confusing.  I've used this graphic recently to try and clear things up.

[source] Albert Barron via LinkedIN

It really is a great explanation of what the differences are.

The other issue I have, again with THE CLOUD is getting some of my leadership to understand that it's somewhat a subjective term.  We can, and somewhat, have a cloud in the building.  Moving to THE CLOUD does not always means moving things off-site.  Just defining it better, or explaining it better, has started to help.  Talk about an over used, not greatly understood term..

Lesson 2 - Initial Thoughts

Lesson 02: The Enterprise Application Architecture 

    Going to take this in a little different direction.  I think my first post under each lesson topic will be just an off the cuff post about my initial thoughts on the topic from the readings based on just my experience and thoughts.

So, Enterprise Application Architecture:

    This is one of the pillars of Enterprise Architecture.  There are a whole slew of applications that are required to make a business or organization run.  One of the aspects of creating an Enterprise Architecture is analysing the current architecture and searching for gaps and redundancies.  Those gaps and redundancies are generated from a number of different events.  In most cases it comes for mergers and acquisitions.

    The value of Enterprise Application Architecture aligns with the value Enterprise Architecture as a whole very well, hence why it is one of the pillars of it.  That value is derived from the standardization of applications for the enterprise. This allows for lower costs from things such as licensing, administrative overhead, and training.  It can also have an effect on security by limiting the amount of software products that have to be tracked for things like security patches, etc.  Another benefit and value of a well defined Enterprise Application Architecture is the ability to make more efficient use of data in the Enterprise.  This is mainly seen in the sharing of customer data to not only provide better customer service but for things like targeted marketing.

    One of the difficult aspects of Enterprise Application Architecture is getting everything to work together.  That is the goal of ERP, which often misses the mark.  And now with the proliferation of hosted services you are seeing more and more companies outsource certain pieces of their enterprise applications to 3rd party vendors.  Also with the expansion of telecommuters, offsite employees, and BYOD (Bring Your Own Device) a lot of these Enterprise Applications are becoming web services, security becomes an even bigger concern.  The plus side of them becoming web services though is the lack of specialized software that has to be loaded.