The Basics of Mobile Device Security

It's come to light recently that NASA has lost around 48 laptops over the past few years, all of which did not have any security protection, not even encryption. For a large company, this is unforgivable, they should know better. Even for a small company, really there should be no excuse not to put in place basic protection for your mobile assets.

However, the task gets more tricky now that there's a growing BYOD (Bring Your Own Device) culture sweeping the office. When people use their own devices, what right has the corporation got over the device? I think it comes down to two basics:

• Does the device attach to the company network, i.e. actually sit inside the corporate firewalls?
• Does the device hold, store or manipulate company data, i.e. data that is owned by the company?

If you can answer "Yes" to either of those questions then regardless of who owns the device, you and your company must insist that the device has certain security capabilities implemented. I would insist that they have:

• User-ID/Password Secured Login: No computer should hold company data that isn't at least secured from prying eyes by a password to log in. This goes for mobile devices as well as computers - most now have the ability to use either a passcode or swipe-code (not just the basic swipe) to enable access.
• Anti-Virus/Mal-Ware & Firewall: Another basic, but many people don't bother. For Windows based devices, it's absolutely essential, but even on devices that are supposed to be safe (Apple/Linux), you should probably insist on it.
• Data Encryption: This should go hand-in-hand with the system log in requirement. Most systems have the capability to encrypt data, it should be insisted upon.

If the person who's device it is declines to implement these requirements, then you must decline access to your company's network and data, it's as simple as that. The IT department needs air-cover from the CEO to ensure people don't creep round to the back-door and get access by pulling a favour.

If you want to go a few steps further, I'd suggest two other requirements:

• Tracking Software: Individuals can implement tracking software on their devices very easily, many are free private use. Prey being a good example.
• Remote Wipe: More devices are now getting the ability to instigate a remote wipe, but there are also 3rd party applications that will do the remote wipe for you.

Above all, pro-actively manage this so you don't have an incident down the line. Put in place a policy that applies to all devices being used within the company regardless of ownership and insist that your employees stick to it. Make sure it's regularly communicated, that you do random audits and people know the consequences of not sticking to policy.

How to find good developers

Most of the time, those who need developers are not themselves going to be developers, so when you're the CEO of a small company in need of a developer, how can you go about finding the right developers with the right level of experience for your website, application or mobile app?

Firstly, let me make things clear with regards to applications. If you're not considering commercial off the shelf packages rather than inventing it yourself, then you're mad, In all likelihood a package already exists to do what you want to do. No, really it will. Go look and save yourself a lot of heart-ache.

Now, if you're still determined to develop something yourself, you need to be sure that you're getting the right person or people to do it for you. So, how do you know? You're not a coder, you've probably interviewed and assessed many, many individuals in your time, but from the interview process you'd never know whether they can code or not. Here's some news: You don't need to because someone else knows for you.

If developers are who they say they are then they'll have a long list of happy and successful clients. Taking the time to take up references is the way to ensure that you get someone who is capable of delivering what you want.

The important bit is not to take up just one reference, but to take up several, maybe as many as five. It should only take you about half an hour to do all five, it's not a big time-waster. You need to take up several because developers can always find one client who'll say they were great, but if they're not that great, they're going to struggle to find five who'll be willing to sing their praises.

On top of that, here's the kicker: The actual development skills the person has will probably end up the least important part of someone's package for you. If your developer can't communicate, can't take your hazy, high level requirements and produce what you really wanted, can't manage their time properly and give you accurate estimates and deliver on time, then you don't want to work with them. Guess what, all this can be gained from the interview and a few decent telephone conversations with the candidates references.

So, don't get hung up on coder technical tests, go talk to their clients recent and in distant past and do a decent face-to-face interview. That's the best way you can find out how good someone is going to be for your company, not by them getting more than seven out of ten on a technical test.