Welcome back, and welcome to the almost-weekend! It’s been a busy week in the data protection and compliance world, which has given us some pretty great links to share! This week we bring you a battle between the beauty of code vs the security of it, an IT disconnect, employees gone rogue, and more!
Warning: You may want some popcorn for the link picks below!
3 Ways to Avoid Designing Boring Compliance Training – @Articulate
Corporate compliance training, much like the flight attendant’s pre-takeoff monologue, is a required part of doing business. We all accept this. But does it have to be so boring? Isn’t there a way to spice things up so the regulations seem less dry, and maybe even interesting to a listener?
In the post linked above, Articulate breaks down three ways to design more interesting compliance training. We won’t give all the secrets away (as always, you need to click through for that), but our favorite is the idea of using a scenario-based approach. Using realistic scenarios, scenarios that make the training relevant to your staff’s every day job functions, not only makes the training more interesting, it makes your staff more likely to retain the information. While creating your own training may not be practical for enterprise companies, we really like their message of keeping training interesting, engaging and, well, not boring. So get rid of those dusty PowerPoints, and adopt a compliance training program that is built with the end user in mind!
Identify and Stop Rogue Employees Before They Become a Security Threat – Troy Moreland, @tmoreland
I’m not going to lie. I somewhat fell in love with this post. In it, Troy Moreland introduces us to three types of rogue employees who wreak havoc on our organizations. I won’t ruin it for you by telling you what they are (really, you want to read this one), but it’s a good reminder that it’s not the cyberhackers with malicious intent who are most often causing us headaches. It’s the people who were invited inside our networks and are acting, well, human.
The article argues that the surest course of action to protect the data, privacy, and stature of your organization is to trust access management software to grant employees access to resources only when they need it. We hear that. However, we also think ongoing employee training is a pretty good idea. How else are you going to get those rogue employees to fall back in line?
How to Reduce the Disconnect Between IT Policy & Employee Behavior – @Breezy
A disconnect exists between the security folks within an organization and staff—one group is busy putting procedures and policies in place to protect the organization and its data, while the other is very innocently accessing company data from free Wi-Fi connections (73% of consumers, according to one survey cited in the article). We already know this, and we understand that we need to bridge that gap. But how?
According to the article, at least part of the solution is employee training. And not one-time training, but ongoing training that is geared toward improving organizational compliance, expanding security knowledge, and changing poor security behaviors. We like this so much we could have said it ourselves. In fact, we have!
The Tragedy of the Bloomberg Code Issue – Richard Bejtlich, @TaoSecurity
This post from Richard Bejtlich really got our attention this week. In case you missed it, Bloomberg recently issued a 38,000-word opus on programming, computers, and the importance of software, entitled What Is Code? The piece, itself, is really quite beautiful. But that’s not what caught Richard’s eye.
What did catch his eye was that nowhere in those 38,000 words on the importance of software did the article talk about the security of that software. Richard writes, “When someone communicates, what he or she doesn’t say can be as important as what he or she does say.” Strong words. To him, the omission underscores a major issue—many developers continue to act unconcerned with the security of the software they’re creating. The implications of that are obvious not only to those in the security field, but, hopefully, to everyone reading. We encourage you to make time for Paul Ford’s piece on code, as well as Richard’s response to that piece. They’re both worthy discussions.
(Did we miss something good? Share it in the comments.)