The Time I Bought a Raspberry Pi – by Farah Khan

Farah Khan is a core Systems Engineer at EMC. She received her undergrad degree in Criminology (minor in Arabic) at University of Maryland, College Park (Go Terps!) and is finishing up her Master’s degree in Systems Engineering at Johns Hopkins University. She has previously worked for a couple of different software development companies in the software testing/DevOps domains. You can find her tweeting sporadically, in between yoga classes and coffee shops.

Have you heard of a Raspberry Pi? An Arduino, a Photon, a Beaglebone? You know, those tiny palm sized computers? I kept hearing about them, but I didn’t understand the depth of their capabilities. I researched on a few, and found that the Pi was originally intended to bring computing to remote areas of the world- to spread the knowledge of technology to previously inconceivable locations. A couple engineers I spoke to highly recommended the Pi – for its price and power. The next logical thing I thought to do was to go out and buy a Raspberry Pi (I really just went to Amazon and searched for a Raspberry Pi, and ordered the first one I saw).

What am I going to do with it? Well, what I want to do is build a light show. I want to attach some LED’s to a VMAX, program the lights to be powered by the Pi… and hopefully remotely control it. I’ve been researching a dozen tutorials on LED light shows with programmable interfaces to control the lights flashing on and off. There are engineers within EMC who have been incredibly generous with their time to teach me (and others) about what they have learned.

But here’s the catch: I may have worked in software development companies, but I didn’t grow up soldering wires together. I may have deployed code updates to clients’ production servers, but I haven’t created scripts from scratch to automate a complete process. I may not have grown up an engineer, but I am learning to become one each and every day.

And that is the purpose of DCLabs- to enable an engineer to truly feel like an engineer. DCLabs is an initiative I’ve started within EMC, modeled after the famous PacLabs in the Pacific Northwest. It’s intended to reflect the natural progression towards open source that our industry is moving in (if not already there). DCLabs is meant to be an open environment where anyone can brainstorm and learn from not only themselves, but others as well. There may be folks who are a couple steps ahead of you but also started out at the same place as you. It is, by definition, a place to make stuff- whatever that “stuff” is. It’s a time and space to collaborate with other passionate individuals who may want to also learn code and eventually solve problems via automation.

Shifting The Focus of Our Security Lens – By Brian Tobia

I was at a meeting recently with both the security and virtualization teams in the room and they were having trouble connecting security policies and objects that lived in each of their realms. A colleague of mine refers to this as the Rosetta Stone problem in which the security team is usually speaking a different language than the others. What is seemingly important to one team usually doesn’t resonate with the other. The two then become disconnected and one of the biggest advantages an IT team has, information sharing, can be completely lost.

So I came up with an analogy to try and help bridge the gap. Instead of looking at things in terms of IPS/IDS policy, firewall rules, vApp’s, or vDS’s, let’s think about attributes and behaviors of the one element that all teams share in common: the user. If we look at how, say medical insurance polices, are written, every trait about a person is considered and this is the core of what the policy is made up of and also how much it costs (it always comes down to dollars, right?). What if we did the same thing for security policies? If each group or piece of infrastructure that we are trying to secure could communicate back elements about a user, we could combine these all together so not only would we have a more comprehensive security policy, but we would also be speaking the same language.

In this model, security policies now become much more dynamic and rulesets that are active across devices are much more adaptive. You can move from having an environment-wide VDI policy for internal users to having a virtual machine whose policy and access level changes to fit each user as they login or logoff. This not only closes many of the gaps we have with current “Swiss cheese” firewall or security device policies, but it also locks down many communication paths that are most likely unprotected today to the most restrictive set.

I mentioned information sharing before and this is really where open standards and integration between all the security tools in an environment can play well together. The first advantage here is the ability to enforce consistent policy based on user identity across an entire infrastructure. These can be things like Active Directory Group, geographic location, login history, the nature of the access request, etc. All these ingredients can be combined together into something like a recipe that dictates what the security policy should be. For example, the security policy being enforced if I’m sitting in an office accessing servers in the datacenter or if I am connecting from an airport in a new country that I’ve never traveled to could be very different.

The other big advantage of this user-centric approach to security is the increased information flow between solutions. If you think of all the security controls in your environment as a chain of services instead of individual pieces, information about what actions have been taken or what user identity attributes are present can be passed along this chain. This now allows for a device down the line, say Device C, to make a decision or modify policy based on outcomes that have already been produced by Devices A and B. Not only can each control now be smarter by utilizing this additional information, but now you get a global view and enforcement of security policy that is making smarter decisions.

Now notice I didn’t mention any product names…that was on purpose. We’re still getting there within the ecosystem of solutions. Whether it’s open source tools, open API’s, or just vendors working together for these integrations, I hope that shifting our viewpoint from being more device-centric to the magnifying glass now being focused on the actual user will result in better solution collaboration and a wider adoption of newer security technologies. Additionally, if security teams are less isolated from being left out of the design process and also if their reputations can be a little less tarnished from all this, it wouldn’t hurt either 🙂

Brian has been an IT professional for over 10 years in various customer-facing consultancy and technical roles. He specializes in virtualization, networking, and security technologies and holds various industry certifications such as: VCAP5-DCA/DCD, VCP4/5, VCIX-NV, and CISSP. He has authored multiple courses on networking and security topics and is an active member in the industry communities. Brian was also nominated as a VMware vExpert for the past 4 years for his work within the VMware and partner communities. He currently works as a security and compliance specialist for the NSBU within VMware.

The End of VDM30in30 2015

IT’S FINALLY HERE, the 30th of November and the end of VDM30in30. What an amazing experience, I have learned a lot from this experience. I have learned that while I like writing my brain is limited to the number of posts I can do in a month. I figured out that I am comfortable with my normal erratic posting cycle.  I have also figured out how to plan out a month’s worth of writing, and organize ahead of time my schedule and posts.

Thanks to vMiss and the whole VDM30in30 crew, it really has been a lot of fun. December starts my Season of Guest Blogging series and I am really excited about that, look for the first post in the next couple of days.

Thank you all for reading and hopefully it hasn’t been too annoying.