Securing Legacy Windows Applications

Question:

What are some techniques for securing legacy Windows server applications using virtualization and/or sandboxing?

Answer:

……,

I do come across these legacy applications everyday and you are right they are not going away and we have to deal with them.

VMware and the other virtualization solutions will not make legacy windows applications more secure (or less secure) . They will just virtualize legacy host systems and fill the need for multiple hardware hosts. You may certainly choose to segment hosts via virtualization, if you believe that it is easier to apply high end IPS/FW/Content security systems inline. This is technically possible in several ways,

1- Deploying hypervisor behind security controls

2- Deploying virtualized security appliances in between vm images.

Your options are not that much different on non-vm deployments. Legacy windows systems are tough to secure for the following reasons:

1- They are usually deployed on vulnerable operating systems, the patches are not available for the operating systems.

2- Host based security controls are usually not compatible (HIPS, AV, FW, Logging, Identity Management etc)

3- Ancient communication protocols are used (RPC, older network stacks, clear text non authenticated file transfers etc)

4- Don’t have the developers of the apps at reach, it is not easy to patch application vulnerabilities…

And the list goes on for the reasons that you already know.. Here are practical solutions: 1- Deploy file integrity monitors, registry monitors. These MD5/SHA1 based tools are independent of the OS, they bring some security. You need to identify critical files/filesystems yourself.

2- Migrate user management to new systems if possible (this is usually not possible but try – avoid NT4 domains, allow local admin users only). Migrate old databases/database connectors to new ones if possible (applications stays intact /data moves to a new home, technically to a more secure one)

3- Segment these servers, they will be compromised since they cannot be properly secured. Do not keep them in the same segment with other “decently” secured hosts/applications. If possible use 1 new segment per host. Usually it is difficult to change IP settings so you can use transparent firewalls/IPS at Layer2

4- After segmenting , assume that these legacy segments are untrusted, apply the security controls that you apply to untrusted segments.

5- Run vulnerability assessments continuously, and know your vulnerabilities. Run your action plan based on the findings…Pen test if the stakes are higher.

6- You will probably see buffer overflows, monitor uptime and get curious after unplanned reboots ,systems halts

7- Log everything at network level (not on host or at application level). Allow access at need to know level. Restrict access by any means (IP, client etc).. Make sure that you have audit trail.

8- Have a migration plan, if not make sure that your risk statement includes the risks associated with these hosts.

Good luck, cross your fingers,

cheers,

- yinal ozkan

Productivity Metrics

Question:

What do you think are key productivity metrics for an infrastructure operations group? What according to you are key productivity metrics for running an infrastructure operations group.

Answer:

That is a tough question. I would start with definition of productivity since it is not a generic metric like uptime measurement…

Productivity is a simple measurement of input vs. output. There are several mathematical models but I would recommend staying simple.

The inputs are usual suspects; they are the resources you have: time, people, and money… You may turn each input into another but I would recommend staying with three.

In productivity metrics, my approach is to compare the delta in output for a fixed input. That is why it is slightly different than regular metrics such as plain uptime, or MTTRs.

I like the COBIT classification for the metrics:

Quality Principles: Cost, quality and delivery fulfillment.

Fiduciary Principles: Effectiveness and efficiency of operations, reliability of information, regulatory compliance.

Security requirements: Confidentiality, Integrity, and availability

But it is easy to classify in different ways, the idea is to measure productivity metrics instead of raw metrics (build a baseline for an input and start comparing a baseline of metrics and get an idea on the productivity for certain input)

For the key metrics representation I would go with %#$” (percentage, number, dollar and time,)

The outputs at infrastructure operations to build comparative productivity metrics can be (but not limited to):

Per Role Outputs:

# Last year Level 1 Engineer was closing 8 priority-1 tickets a day this year 20

# Last quarter Level III engineers were completing 2 projects/month, this quarter 1

% Percentage of positive feedbacks per role

Time Based Outputs: Our “Mean Engineering Fix Hours” time was 2 hours now it is 90 minutes..

Time: MTTR/MTBFs baselines

Time: Unplanned downtime baselines

Time: Cycle time provisioning a new infrastructure component was 1 week now it is 3 days

Money based:

$ Per ticket cost was $100 now it is $20

% Percentage of infrastructure costs charged back to business was 50% now 80%

$ Cost of running my team was $x now $y

$ Unplanned downtime impact in $ terms was $x now $y

Quality Based

% Percentage of planned/on time completed change requests – over time/cost

% Percentage of systems compliant with policy requirements – over time/cost

% Percentage of systems with the required OS/patch levels – over time/cost

e.g. Last month our team had 3000 hours 90% of changes were within planned range.

It is easy to deploy custom metrics based on your environment as long as you stay with the productivity focus. You can also build your metrics from the frameworks you are following (PCI, FFIEC, COBIT etc)

Also in reporting you need to explain surges, drops and trend changes that effect productivity metrics.

Yes, it is not an exact science but as it is said “you cannot improve what you cannot measure” . I also recommend Andrew Jaquith’s “Security Metrics” book even if it is security focused.

regards,

- yinal ozkan