Converting Assets to the Cloud from a Cybersecurity Standpoint

Converting assets to the cloud is something that MUST be undertaken from a strong and unwavering cybersecurity standpoint.  This is non-negotiable.  When our company started in 2001, we were concerned with testing and assessment of the network security environment.  Yes, we also conducted what we called an Environmental Audit, which considered everything physically and environmentally (including Social Engineering) within our heavily regulated clients’ setups.  We also covered the Disaster Recovery/Business Continuity angle within this audit.  

Back at the start, SPI started by writing network security policies for banks and hospitals.  Banks were told in no uncertain terms by the passage of the Gramm-Leach-Bliley Act of 1999 (GLBA) they must started bringing in a neutral third party to test the security soundness of the network and environment where sensitive data and other assets were stored or used.  On the other hand, with our healthcare sector, HIPAA, which came out in 1996, took years to gather any ‘teeth’ as far as hard rules for hospitals, etc.  But finally, the FINES grew and grew, and, whether you were a one-doctor office or Advent Health, there was a particular tier of fines just for you!

Fast forward to the present we not only have to test the cloud for property cybersecurity controls; we now have countless applications, rolling out at the speed of light (to keep ahead of your competition in providing ‘convenience’ for your customers, that we have a three-pronged arena, called the cybersecurity environment.  Unfortunately, security has seldom been convenient.  Microsoft used to ship its Windows system with ‘all ports open’ (all ways in for the bad guys, that is), and leave it to the poor IT director to close everything except what was truly needing to be left open.  All that convenience helped ramp up the cybercrime wave at lightning speed during the 1990s and early 2000s.  

I remember being at the roll out for MS 2000 in Chicago, I think it was.  Some MS executives proudly announced to the thousands assembled something along the lines of MS 2000 being (pick one; I can’t remember which) “Totally secure,” or “Hack-Proof.”  Within about twenty seconds the whole thing was taken down in that auditorium!  Amid red faces from MS executives and laughter.

Microsoft security has come a long way since then, obviously but people want easy to use tools and software.  I knew the ugly underbelly of all that Internet shopping and automation fun with ease would rear its ugly head.  Most strong security measures are easier to implement now, by far, but not always convenient or simple.  Such is the way the cybercrime world has evolved.

Other than the MS route, one of the only secure things around was the Linux language, favored by, well, programmers and other hard-core geeks.  Why?  It was difficult to use and had security controls built in to make it tough to break.

Cloud computing has so many benefits I could write another paper on that.  Here we will surmise the best points and practices, compacted for (I hope) easy digesting, for any savvy IT management team to deploy.

-Assessment and Planning:  

This section is really two parts (in order):  First, you need to identify all the IT assets you plan to migrate to the cloud.  Second, you need to assess threats and vulnerabilities which can arise during this process.  Another name for this is threat modeling. This is simply a formal term for considering such things as data exposure, data integrity and unauthorized access.  

-Evaluating a Potential Cloud Provider (CSP):

Any CSP you consider should have a strong track record in cybersecurity issues.  Be sure to review their security practices, data protection mechanisms, compliance certifications and incident response processes and procedures.

Classification of Data:  Make certain you classify your data based on compliance and sensitivity requirements.  Spell out the difference among internal, public, and private data.

Encryption:   Be certain you implement strong encryption for all data, in transit or at rest.  Either you can use the encryption mechanisms from the cloud provider or use third-party encryption solutions.

What does IAM stand for? Identity and Access Management.  For the tightest access controls, configure them based on the principle of ‘least privilege.’  You can use IAM tools to manage all roles, user identities and permissions.

Use MFA:  Enforce this for accessing critical resources as well as sensitive data.  This gives you another layer of security beyond just using passwords.

Network Security Groups:  Use NSGs to define firewall rules as well as restrict inbound as well as outbound traffic at network level.

Virtual Private Cloud:  In order to control both inbound and outbound traffic, use VPCs (set up at isolated network environments).

Web Application Firewall:  Set up a WAF to protect your applications from attacks via SQL injection and cross-site scripting, both common attacks from the web.

Coding:  Be sure that applications being migrated to follow secure coding practices.  Get any vulnerabilities and potential security weaknesses before migrating assets to the cloud.

Security Information/Event Management/(SIEM):  Integrate a SIEM solution to analyze and centralize security and -related events and logs.

Logging:  Set up detailed logging for applications, cloud services and network activity.  Log information can be crucial to help spot suspicious activity.

How complete is your incident response plan?  This plan addresses cloud security should be very strong.  Many times, such plans fail due to poor assignment of duties and activity to the DR team.  Be very clear about this to avoid vagaries amidst an emergency.

Recovery and Backup:  This has been a basic cybersecurity process since the beginning of networking, but we still see lack of priority on frequent backups (and patching, by the way) of all your assets including those related to cloud migration.

Leave a Reply