[cs615asa] HW-N - "This is Fine" – New Approaches to Hardware Security Meetup Summary

[Justin Barish]

Hi all,

For our meetup, we all chose to attend “This is Fine” – New Approaches to
Hardware Security by the Downtown NYC Tech Meetup group (
https://www.meetup.com/Downtown-NYC-Tech-Meetup/events/260286464/). We all
collaboratively created this write up of the event. The event featured two
keynote speakers, from the companies Anjuna (“Secure Deployments of
Sensitive Applications without Worrying about the Infrastructure” by Yan
Michalevsky, CTO & Co-founder) and Rubicon (“Secure Identity to Control the
Edge and Enforce Data Sovereignty and Compliance” by Rod Schultz, Chief
Products Officer). Also, as a fun fact, it took place in the Telstra
office, which from HW3 we saw was a Tier 1 provider.

Summary of the Event: This event was to learn about two Companies Rubicon
and Anjuna and the various technologies they are building in order to
secure hardware. In Anjuna’s opinion, the security perimeter should be
moved from the host to the app, making app completely protected from the
environment. Anjuna used secure enclaves with technologies such as Intel
SGX and AMD SEV to isolate execution units and to encrypt the whole memory
space, and thus prevent another process, regardless of privilege level, to
be unable to read to interact with the victim process without any secret
keys. Furthermore, it is implemented as a wrapper program effectively,
allowing easy deployment. It is simple because it avoids code modification
and DevOps process changes. Anjuna also integrates with existing workflows
and orchestration tools for both legacy and cloud-native environments,
which avoids the underutilization of server infrastructure, since secure
applications can safely run alongside untrusted applications.  Rubicon took
a different approach and secured IoT devices using encryption keys to
encrypt, sign, and uniquely identify hosts. Simply put, they provide an
identity platform which works in two parts: an identity agent, and an
identity server. The identity agent is a simple tool embedded on an IOT
device that communicates via API callbacks from the customer application.
The agent then communicates to Rubicon's cloud service for access to
different control policies and key management. The principle of this
defense was to prevent the use of dictionary and rainbow attacks (default
passwords used with IOT devices), as well as significantly limit the attack
space, so that if one host is compromised, that doesn't lead to other hosts
being compromised.

Relation to Class: This event showed a strong relation to our class by
talking about issues that are relevant to the real world, and how they can
be solved. These include assuming that an attacker may be able to take
control of your system, or might be able to maliciously utilize a
privileged users' credentials in order to interfere with the running of
other programs on the system. Anjuna uses hardware level secure enclaves to
prevent this: Various services are loaded into these enclaves, forbidding
the access of the data in memory. Rubicon also showed how minor IoT devices
such as smart watches or light bulbs are attacked, and how small, repeated
attacks can have significant consequences, making the need to secure them
as important as securing other sensitive servers. Rubicon also addressed
the issue of how to properly authenticate and authorize IoT technology in a
scalable matter, which related to the topics of authentication and
authorization we discussed in class. Both of these topics were extremely
important for the design and implementation of a secure system, which is of
utmost importance to a Systems Administrator.

Why we Chose this Event: This event has great relevance to the real world
and as mentioned above was hosted by a Tier 1 provider which was an
interesting experience. As IoT devices are becoming more and more prevalent
in the physical and digital world, it is important to not only secure them
but to ensure that they can't be compromised and used to take down large
networks. It was also a good learning experience to see how people are
building on top of preexisting technologies such as the Intel SGX and AMD
SEV to secure not only the storage of their processes but also the runtime
itself. This is something that we feel will become more common in practice,
and Systems Administrators will have to learn to deal with the security
vulnerabilities that are inherent in an inter-connected world. Plus, we
were also able to experience the workplace and lifestyle of a prevalent
tech company.

What we Learned:

   - The principles of Secure Enclaves and (briefly) how they work.
   - How software can be executed securely even on an insecure system.
   - A brief history of information and how it can spread while also
   disrupting the current flow of information.
   - The vulnerabilities of a hardware system hosted on the cloud.
   - Tunneling between two VMs with enclaves for shared memory.
   - Cost-benefit analysis between performance and security of Anjuna's
   solution could be different from the certain cases.
   - VMs in one server which share hardware resource (e.g. hard drive,
   memory) could cause security problems if attackers gained root privilege to
   just one of the VM's.
   - Both topics talked about the term "Secure Identity", which is a big
   topic in the security area.
   - Key Management is extremely important and difficult in the field of
   IoT. It is especially important following the Dyn cyberattacks of 2016
   (mirai malware).
   - System Administrators should consider potential vulnerabilities even
   if they are not in the threat model.
   - We can make our execution units isolated from the server to improve
   the security.
   - We can also divide execution units in different security zones.


From,
Justin Barish, Brett Biggs, Rob Herley, Thomas Pyle, Sri Vallabhaneni,
Aimal Wajihuddin, Huajie Xu, Chengzhi Yang, and Yuchen Zeng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.stevens.edu/pipermail/cs615asa/attachments/20190419/dc1cefac/attachment-0001.html>