Baking in security with a technology, practices, projects approach

How can we keep our IT systems secure?

It comes down to baking in the security from the beginning. Each new technology initiative is an opportunity to increase our overall security.

So we get a new project. In the beginning phases, while evaluating projects, we push to ensure that security is a consideration and that the vendors are asked about the security features as well as the functional features. Once the technology is selected and purchased, we work with the project team to ensure that security steps are included in the project plan. We pull the software in-house, install it, beat up on it, and assess for any vulnerabilities. When the project completes and the system is released to the end-users, it goes out the door in a secure state.

Such a secure state comes in part from experience, in part from training, and in part from industry practices. Proven practices such as deployment guides or NIST publications are excellent sources of information security. As part of any project or as part of securing any technology, such practices should be tried and evaluated. The goal is to apply not only what we know works, but also what the industry has found to work.

Researching and applying proven practices needs to be a task in every technology project. Take a Linux or a Windows server, install the new software for the project, and apply best practice guidance to it. At the very beginning of the project, lock down files and registry keys. Work thru any issues that the security may cause early on in the project before other departments get involved. The result is a system as tight and neat as is possible. By baking these steps into the project plan, we ensure that new systems come online securely.

Security is technology, practices, and project-centric.

If the Windows Server uptime is more than 30 days, then the server is a problem child. That’s a basic rule of thumb.

Windows Updates come out every month. Every month, a Window Server should be updated and rebooted. If it is not, then there is a problem.

One way to check for this is to match the current crop of updates to the applied updates on the server. This can take a bit of time and gives a better indication of the server state. A quicker way is to scan for Servers with uptime >= 30 days.

Below is a basic script that checks and reports the uptime. It’s trivial to modify into a problem child scanner.

Bonus tip: reboot your servers both before and after the updates. This minimizes problems applying the updates that may occur when files are open or processes are hung.

Happy patching.

‘—————————————————————–
‘
‘ Name:   uptime.vbs
‘
‘ Author: J Wolfgang Goerlich
‘ Date:   2005-05/07
‘
‘ Description: Report uptime and possible concerns
‘
‘—————————————————————–

Option Explicit

‘ Dimension variables

Dim wmi ‘ SWbemServices, WMI interface
Dim wns ‘ WMI namespace
Dim wql ‘ WMI Query Language
Dim computer
Dim oShell
Dim results
Dim os
Dim D, H, M, S

‘ Get the computer name

Set oShell = WScript.CreateObject(“WScript.Shell”)
if WScript.Arguments.UnNamed.Count >= 1 then
computer = Trim(LCase(WScript.Arguments(0)))
else
computer = LCase(oShell.ExpandEnvironmentStrings(“%ComputerName%”))
end if

‘ Get the uptime

wns = “winmgmts:\\” & computer & “\root\cimv2”
wql = “Select SystemUpTime From Win32_PerfFormattedData_PerfOS_System”

Set wmi = GetObject(wns)
Set results = wmi.ExecQuery(wql)

For Each os in results
S = os.SystemUpTime
Next

‘ Report the uptime and status

M = S \ 60 : S = S Mod 60 : H = M \ 60 : M = M Mod 60 : D = H \ 24
Wscript.Echo “Computer: ” & computer
Wscript.Echo “Uptime: ” & D & ” Days, ” & H Mod 24 & ” Hours, ” & M & ” Minutes”
If D >= 2 then Wscript.Echo “Problem child!”