IS Policies - ISO27001

Data is becoming the biggest and most important asset that any company has, and it's important to ensure that your company data is properly managed. From an IT perspective, this can be managed through an Information Security Management System, according to ISO:27001. This International Standard is a great reference when putting controls in place, or mapping what controls you already have to industry standards.

We started this process by performing a GAP analysis - going through the ISO standard and mapping what controls, polices, procedures and processes we already had in place. We found that most of what we had didn't quite cover everything we had expected it to do. There was also a lot of controls in the Standard that we hadn't addressed.

Our next step was to update all of the policies we had to make sure that they did address all of the controls that they were designed for. We were able to amalgamate a lot of them and expand the ones we had left so that by the end we had fewer, but more detailed policies. We collated them all in a single handbook and then created an index spreadsheet that listed all of the policies, the owners, dates for review, changes etc. so that we had a quick reference document.

Once this handbook had been compiled, we went back to the ISO Standard and looked at the areas we had not yet addressed. Some more policies were created and added to the handbook. We also looked at all our our procedures and processes - standardised them all and if applicable we merged them into policies, or added them as appendices in a standardised format.

Once this had been all been done, we split the book into different sections and published them to the different areas of the company. One for the General Staff, consisting of all policies that applied to everyone; one to the HR department that covered... you guessed it, HR Policies; one to our internal IT staff that was pretty comprehensive and covered all of our controls, polices, procedures and processes; and the final section was published to suppliers and 3rd parties that we work with, consisting of policies in relation to SLAs, contracts and other external procedures that we had in place.

We review this ISMS every year at a minimum to make sure that the policies and controls still apply to us and our current use of technology. It has given the staff, management and IT team a lot more confidence in our security and controls and we follow these religiously.

The above description is a very, very brief outline of the work we carried out, which took several months to complete. It is a huge commitment and takes a very large amount of resourcing, but once in place and part of the culture, helps to increase your security posture and gives your company and others confidence in how you process and store your data.

Server 2008 R2 - server starts up but can't log in or use resources

Monday morning after a week off and surprise surprise, a call at 6am to say the system is down!

All servers are working - apart from one. The one that stores the user profiles (we discovered that our fail-over wasn't working, that blog will come later!). At the console we're met with the Ctrl+Alt+Del screen and are able to enter our credentials. We tried both domain and local users, but couldn't get further than either Please wait for the User Profile Service with the domain account or Loading Windows Personalisation with the local account. Luckily, with the local account, we could hit Ctrl+Alt+Del and bring up the Task manager.

With the Task Manager open you can select Services and see which services had started correctly and which ones were still in the Starting phase. For us, the Citrix MFCOM and IMA services were still Starting and gave us some clues as to what was happening. Cue a Safe Mode with networking restart and we were able to log in with the local account.

When we opened the Services.msc console we could see that since the last restart, the two services for Citrix mentioned above were now trying to log in with our Backup Exec account. A quick check on the other Citrix servers and we could see that it should be using the Network account. using the log on tab in the services properties, we were able to switch back to using the Network account.
*Quick Note* To change back to the Network account, open the service's Properties, choose the log on tab, click Browse and type in Network, then hit Enter - this will automatically change the account to Network. Remove the password in the boxes below this and Apply and close the properties box.

Complete this for both services and Restart the server. Hey Presto! Server and resources now work. All that's left is to investigate what (or WHO!) switched the log on account from Network to Backup Exec!

\\domain.com\namespace: The Namespace cannot be queried. Element not found.

After we managed to save our SAN disk and have it represented to the server after it had booted (I don't recommend it! Boot the server with the drives presented EVERY time), we had some unusual DFS issues. When we opened DFS Management to check one of the namespaces, it was showing:

\\domain.com\namespace: The Namespace cannot be queried. Element not found.

We could successfully open the folder on the server, but couldn't when trying to access as a network resource. We tried to remove the share on the folder using folder properties but it said we had to remove it from the DFS management console first.

After much playing around, we decided it had to be deleted. So... ADSIEdit > open the domain > CN=system > dfs-configuration > find the namespace you wish to delete and delete it. Open DFS management and remove the problematic share from view. Next - make sure you restart the server! We spent the next half an hour troubleshooting it - all it needed was a restart. This kicks DFS into play again and it catches up with itself.

At this point, open the folder properties, remove the option to share from advanced sharing and then set it all up again using the DFS Management console.

In all, quite a simple fix - but as the saying goes, it's easy when you know how!

EVA 4400 Cache Battery problems - EventID 1511 and 1521

It all started so well. At 7am on my day off (!) the phone went and I was told that no-one could log in successfully. Several people were managing to get in with a temp profile but couldn't access any local apps. Luckily most of our apps are run via Citrix, which was still available via Receiver and the Start menu.

Upon inspection, lots of EventID 1511 and 1521's appearing. The advice online - rebuild the corrupt profile. Well, this was happening for the entire office of over 100 people so that was an immediate no-go.

(***In a nutshell - if you get EVENTID 1511 and 1521, it usually means a corrupted profile. In our case, the SAN drive that contained the profile folders was not presented successfully to the server, so the profile folders were not available to the users as they tried to log in.***)

We're in the process of migrating from our old EVA 4400 to the latest and greatest HP has to offer. However, being 'in the process of' means we're running both systems in parallel. The disk from the new EVA was working fine. The disk from the old EVA just shows up for 5-10 minutes after the server boots up and then disappears from view. Nothing in Disk Management either. We removed the automatic updates that installed the night before, nothing. Swapped the Fibre Card over, nothing. Checked Command View on the management system and the EVA reported full health - apart from a Cache battery on Controller 1 having died. 

The Cache battery had died on us several months before, but had no side effects on the system. This time, for some strange reason, because the cache battery on Controller 1 had died, the MPIO routing from Windows died with it. It steadfastly refused to re-route the traffic to Controller 2 and as such MPIO on the server decided that it couldn't see the drive at all. Even using CV we couldn't get the system to fail over to the working controller 2. Very frustrating. Luckily we had a spare cache battery laying around.

After swapping the cache battery, bingo - the drive reappeared! Controller 1 came back up and the system went back to normal - almost. 

However... Read the next blog for the DFS fall-out issues!