Linkedin “Intro” iOS app…slurp slurp slurping ur emails sitting on our servers

Bishop Fox (formerly Stach & Liu), a very well respected ICT security firm, has some issues with Linkedin and their latest app offering called Intro. It seems that there is a bit of a risk using this app as it forces all your iOS based device emails to go through Linkedin servers.

http://www.bishopfox.com/blog/2013/10/linkedin-intro/

If the findings of Bishop Fox are correct the implications for any data reliant business could be quite severe. Even if it is only the metadata they are looking at, it is still a gross invasion of privacy and in terms of regulatory compliance could well spell trouble as well.

This is why, when looking at new business practices like “bring your own device”, there are inherent risks that the business needs to be aware of. In this case it isn’t even a BYOD issue. It is one of trust being possibly hugely violated by Linkedin. When you look implementing new technologies there are reasons why you test the technology, understand the technology in some depth, understand the implications of the technology and security surrounding the technology.

Just sitting back and hitting next on the installer without some research is a path to pain.

And a possible violation of your organisations ICT policies.

I would also suggest looking into suitable data/email encryption  technologies as a standard business practice.

Advertisements

What is the single most important KPI in ICT?

For me its all about the availability of data based on the needs of the business.

If you are offering ICT services (internal or external) you will always encounter (or rather you should encounter these words!) – Service Level Agreement (SLA).

SLA’s are all about setting a level of expectation between a service provider and a customer. Yes…your service desk, your engineers, your developers are all service providers towards the customer (business). All work towards the delivery of a solution within a certain time frame, if you go outside of that time frame there are usually some forms of penalty.

What does this have to do with the single most important KPI (key performance indicator)? Well from my perspective data is essentially the business. Sure you can manufacture something and sell it, but to build something you need the data first. Be it the plans or even the code running the robots or the work instructions for those who work on the assembly line. Data drives everything in a business.

What happens if that data is not available? What impact on the business? Certainly some data is more critical to a business than other data but all data serves some role in the business, yes even the list of customers birthdays. So when looking at designing services the primary question should be focused around how the business views its data and how it uses data. Taking that knowledge gives you an idea of what kind of availability should be built around your ICT services.

How high up in the list of priorities should your patching be? Tales of woe and gnashing of teeth stopping this endeavour? Or heroes on the front line?

We all know about “Patch Tuesday”, Microsoft release date for patches to it’s operating system, .net and other software. We all have plans around this activity and many of us have processes set up to facilitate these updates. Well, ok, most of us do.

However your ICT estate does not comprise of MS alone. You will have other kit that has software running it. You might even have linux servers as well as switches and routers available from a variety of vendors.

Do you know if these are up to date?

I recall a conversation regarding patching with a group of data centre techies and managers. We addressed the MS side quite easily and with little headache for the most part. However, after an audit, it was apparent that the linux servers had not been patched in years, and by years I mean more than six or seven. Mainly because it was felt that they didn’t need patching when they were rolled out, linux being considered more secure.

However patching is not only about killing exploits. It is also about increasing the efficiency of the software as well as hardware. So these servers were running flavours of linux that were very much out of date, that in some cases had vulnerabilities. All were impacted in terms of running the latest revision of firmware, drivers, and OS.

Then we have the other parts of the estate – switches, routers, firewalls, load balancers, storage devices. Certainly all these can be compromised and result in embarrassing the IT department. As IT professionals we certainly don’t want that, right?

So how do you weigh the risks? There are costs involved, obviously, as well as possible impact on production. I recall one organisation running a update on their back up software that resulted in a pretty major catastrophe by taking the storage array off line.

Keeping up to date with your vendor’s updates is vital as is understanding what the update will do both during the up date and after. Will it break applications for example (with storage), will the device reboot and leave your network unprotected (firewall)? Hopefully the answer is no. However if there is one thing that you should do, if at all possible is test the updates first before releasing. Unless it is a hugely critical security update (and even then I seriously suggest testing before release, and have a back up plan to hand when it goes wrong) you can take time to do this.

If you have to wait for a suitable window in which to do an update then that is ideal to also do testing. Testing tells you if the update is stable, it gives you an opportunity to learn about any changes and certainly should tell you if you can expect any major issues.

Sure patching is a pain and no one really likes to do it because the pain it can cause but as indicated above there are steps that do help reduce or limit that pain. However you need to weigh up the pro’s and con’s as a business.

Ultimately you are protecting the business.

Things one should not have in ones Data Centre, like pigeons.

During a meeting last week I recalled an incident from early on in my career, of something that should never have happened.

I had occasion to visit our company data centre, newly built and opened, for a meeting (my life is really that exciting!). As I had not seen the data centre I was invited over with the carrot being a tour of the machine room. Me being an inveterate lover of data centres and technology (yes…buttons and flashing lights, not my fault! I grew up in the 70’s on a diet of 1960’s sci-fi!) I could not refuse. This facility was not what one would call small or cheap. Had all the latest kit from servers, switches and storage to the best in fire suppression as well as HVAC (Heating, Ventilation, Air Conditioning) and power. Fantastic structured cabling, managed server racks. Enough good stuff to make you want to move in, although the chillers would have been a bit problematic. Given I rather like being warm.

So while waiting at the entrance to the actual machine room, looking through a rather very large reinforced plate glass window, admiring the view I noticed some movement out of the corner of my eye. As one does, waiting at the entrance of a sealed and access controlled facility. At first I thought my eyes were acting up or that I had a particularly bad case of floaters. So I did what every sane person would do and rubbed my eyes and tried to look for whatever it was that I had seen.

After a while I managed to track down this thing that had caught my attention. It was a flurry of white and grey and a bit of pink I suppose. Yes. It was a pigeon. In the data centre. Being rather taken aback I rubbed my eyes again and, yes, it was a pigeon. Flying. Loose. In the data centre.

Around the corner of the area I was in, was the office of the centre director. I popped my head in and asked if they had a minute and and any experience in animal control, being the humourous kind of guy that I am.

The sight of several engineers, managers and a director chasing down a pigeon, that turned out to be breeding pair was something that did make my trip well worthwhile. Downside was that the tour was canceled but thoroughly understandable given the circumstance. Its not often one sees a pigeon in a data centre.

Eventually we discovered what had happened. It seems that during the site survey of the original building there were some ducting holes that ran from the room to the outside and not been filled in. This building having been originally a secure telco exchange. So assumptions were made.

Is there a moral to this? Why yes. Yes there is.

It seems that the NSA has some data centre issues as well.

http://online.wsj.com/news/articles/SB10001424052702304441404579119490744478398

Chronic electrical surges at the massive new data-storage facility central to the National Security Agency’s spying operation have destroyed hundreds of thousands of dollars worth of machinery and delayed the center’s opening for a year, according to project documents and current and former officials.

There have been 10 meltdowns in the past 13 months that have prevented the NSA from using computers at its new Utah data-storage center, slated to be the spy agency’s largest, according to project documents reviewed by The Wall Street Journal.

To my mind, if you are spending millions or billions you should be following some kind of methodology rather than plug every thing in and hope it all works. In my first example, assuming that a building is secure because of its past life is not a good thing. You need to approach the survey (in this case) with a clean slate and probe every aspect of the facility.

In the case of the NSA power issues I find it hard to believe that the power is so flaky as to cause actual damage and what seems to be a huge risk to life and limb. In this case, a unique facility with perhaps unique power needs, cannot be approached in a business as usual manner. There has to be a methodology to be followed. My first question in any kind of root cause analysis would be if there was recognition of the systems uniqueness, to what level had the vendors been involved in the design, and most importantly had there been any testing done?

Of course each outage we experience, or pigeon, is not a time for finger pointing but rather to learn from those issues and ensure that such events do not happen again.

(some circumstances regarding the pigeon incident have been changed to protect the innocent, and the pigeon…but the salient points are true – there was pigeon, it was a new DC, it was expensive and the building was considered secure, and yes the director did chase the bird)

So is it time to drop Internet Explorer as a corporate tool?

Another month and another IE security vulnerability. The browser that just keeps on giving. To the criminal gangs able to exploit this browser.

The latest is yet another javascript vulnerability as reported by>  http://www.alienvault.com/open-threat-exchange/blog/latest-internet-explorer-0day-used-against-taiwan-users

Microsoft do have a little fix tool out for this> http://blogs.technet.com/b/srd/archive/2013/09/17/cve-2013-3893-fix-it-workaround-available.aspx

Apparently a more comprehensive fix is scheduled for the next release of patches on Patch Tuesday (8th of October 2013).

Or…use Firefox with noscript and adblock in your corporate environment. Unless you want to be the next target for a bunch of hackers for hire.

Don’t Panic! Don’t panic Captain Mainwaring!

How often is your organisation seen by your staff, team members, individual contributors as being a bit of a headless chicken when things go wrong? More specifically when there is an outage that affects people being able to work? Especially when the outage last for more than a half or even a whole hour?

I’ve dealt with all manner of outages in different types of companies over my career so far and to be frank and honest I rather enjoy dealing with them. Oh I’m not one of those “let the techies sort it out” kind of managers. Nor am I a leaning over the shoulders micromanaging the techies either. As a manager or rather a leader of a team of technical support specialists I have a very specific function. To resolve the issue as quickly as possible with the minimum of interruption to the business. Indeed it sounds obvious but in practice it is oft forgotten, hence the headline.

I approach these kinds of issues with one constant theme. Communication. If you are not able to communicate effectively, honestly and concisely during an outage you will face a great deal of pain. If you are the lead manager dealing with an outage of epic proportions you have to ensure that the relevant people are kept informed of not only progress but impact as well. The gives other managers the opportunity to galvanise their teams to perform other tasks instead of sitting around and grousing about how bad IT is. Keeping people busy and informed is really a major benefit for the business and for the IT teams. The last thing the IT team needs is answering superfluous questions when dealing with complex technical issues.

The technical team manager is the one who has to be able to implement a communication plan to the relevant people to ensure that the IT team can concentrate on the task at hand. The only person who should be talking to the technical team is their manager. The only person who should allow technical guys to get involved in management decisions/communications is the manager. I have learned this the hard way. Once another manager gets involved directly with the technical guys the issues can be easily lost control off, usually due to the other manager wanting things done for his or her team. It is understandable but is of no use to actually getting to the root cause and resolving the issue. That manager should be concentrating on leading their own team, based on information from the technical team manager.

What is a communication plan? Well it is a process that a manager should follow to allow for the business to appreciate the severity of the issue as well as what is being done to fix it. Indeed it is often not possible to give time scales to start with…which is why the communication plan is not just a one off event. You should be looking to update in a timely manner. By this I mean on a time basis…not an event basis. If you update your business on an event basis you could end up flooding people with too much information. You should look at an update once an hour or half hour…even if there is nothing concrete to report. The consistency of such a report does actually aid in not having people call you. Leaving you to work with your team, as a leader, to resolve the issue. You have other roles to perform in these cases as well. Be it hosting Emergency Change Advisory Boards or dealing with vendors to escalate or co-ordinate resources, or even setting up and manning the “War Room” (web ex sessions, conference facilities and the like). However you must be able to communicate with your user community as well.

So in terms of your communication plan you need to understand each functional area of your business. For example your SAP system for finance might crash and die…do you need to contact HR? Unlikely. Of course if your outage is business wide then you do. Your communication cannot rely only of email…what if your outage impacts your email system? So you need to look at how you get your message across to the other managers. Mobile phone numbers are invaluable. Also invaluable is ensuring that the managers you are contacting understand why they are being contacted and their role in dealing with outages. They might have specialist IT staff as well, who could well be of use to resolve any issues.

So the bullet list of things to do (an admittedly basic bullet list which can be tailored to your business) :

  • Understand how ICT integrates into each functional area of the business and the impact of outages of critical systems
  • Identify the stakeholders in each area: Managers, specialist staff and deputies
  • Ensure you have their contact details: Email and mobile telephones
  • Hold twice yearly meetings with these stake holders to ensure they understand why they are on the communication plan, what is expected from them and to look at any improvements to the system
  • Be clear, concise and honest with your communications
  • Make sure you adhere to any promised time schedule with regards to your communications

This is not an end all and be all but as a start will assist in ensuring that you are looked at as a professional company (or ICT support team) rather than a Corporal Jones.

Small Businesses and ICT…how do you turn over the engine room keys to someone you can trust

Further to my post below from yesterday, I asked myself what would small businesses that have limited technology expertise do with regards to updating software or operating systems. I can imagine that there are many such companies where perhaps the principle of it ain’t broke, don’t fix it is the prevailing mindset.  No doubt it is not an inherently bad thing to be somewhat resistant to change but is that so with technology?

Well I can imagine that long running corporations, running huge legacy systems on ancient big iron, are very nervous of doing anything that might well bring these down and creating adverse conditions in which to conduct business. One reason I would think they do not look to going to new infrastructure, the pain of moving would be incredibly high and perhaps even so painful it brings the business to its knees. However they still do a lot of work to maintain those systems, including code releases and changes of hardware. They tend to do it very carefully. Well the ones that have an understanding of the risk a system failure poses to the business. Of course these businesses are able to hire highly skilled and experienced engineers and systems managers.

Of course not all small businesses (in fact I’d say most small businesses don’t) have huge complex systems or are running legacy code on ancient mainframes. However their technology, if it goes wrong, could have the same impact…it could drive the business under. However the difference is that the small business does not have highly skilled engineers nor managers.

So how do small business approach things like ICT support? Often they outsource their IT to professional managed service providers who do all the work for them or they rely on friends or family. Either of these are not intrinsically bad if they have undergone some measure of due diligence. If you are willing to turn over what is effectively the engine room of your business I certainly hope you know who you are turning it over to and that they are capable!

It might sound awkward to ask your friend or family member if they are competent ICT support people, but would you also ask the same of another company you want to hire to look after your IT? The answer has to be yes. However in both cases do you know  what questions to ask? You are not an expert, otherwise you’d be looking after your own ICT, right?

Well I have a very basic check list you might think of using to ask not only your friends and family but managed service providers as well. Some questions will only be applicable to these managed service providers.

  • What certifications do you (or your engineers) have?
    • Are they relevant to my needs?
      • How?
  • Can you provide me with business or customer references that are relevant to my needs?
  • How long have you been providing support?
  • Do you carry liability insurance?
  • What kind of Service Level Agreements are you able to work to? If I need 24/7/365 support can you provide it?
  • What do you do if you cannot fix my problem within the Service Level Agreement? Do you have an escalation plan?
  • Do you need to be onsite to fix my problems or can you do it remotely? If you are doing it remotely what kind of security measures do we need to put in place and why?

These questions are worded not sound harsh but to get both parties to think about the depth of the support relationship and how important your ICT is to you and your business.  It is not intended to insult your friends or families but would you rather keep your friendship or family member than give them the job in which it turns out they are wholly unable to commit to and it kills your business? When asking these questions to a managed service provider there really ought not to be a problem because if they are any good they will be able to answer them easily. They will also welcome probing questions. If the managed service provider is evasive or unable/unwilling to provide timely answers its a good sign you want to look elsewhere.