0

I'm new to certification arguments. I have an issue with a requirement that is to make an application in a certified Windows 2008 environment.

What are / where can I find a guide to WS2008 CC-compliant setup: which features can I safely install and which I shouldn't (so I have a system on which I could do some tests and 'touch' the features available).

1

Since your question has too many unknowns I'll try to address the most common things that you will probably need on this.

Microsoft has some guides that you can download on this listed on their site under:

Common Criteria Supplemental Admin Guidance for Windows 7 and Windows Server 2008 R2

As well as additional information under Common Criteria Certifications

But this is for THEIR certifications and configurations which yours would be based on top of being configured as they specify. If your application is to be certified as well then you will need to hire an outside company to certify you and that isn't cheap and can take around a year with all of the flaws that they find. Here's one I found on Google and I am not affiliated in any way, just the first result I found.

If you JUST need to validate the installation as per CC then the Microsoft guide references THIS guide.

After installing the OS the CC guide references to follow the hardening guide: Windows Server 2008 R2 Security Baseline

I would advise who ever submitted this requirement that they be notified that Server 2008 is EOL on 1-14-2020 so IF they choose to NOT upgrade to a newer version of Windows then even if it's secured today that it will get hacked once updates are no longer available. There is a migration guide available on that link but I've worked in "legacy" environments and the best thing to do is start from scratch from the OS on something supported then reverse engineer the registry and installation of programs that will no longer re-install on modern OS's and create your own installation scripts to hack together a solution. During this phase I would HIGHLY recommend using snapshots of before any changes on your target VM so you can roll back over and over until you get it figured out. Then do a final roll-back and run your latest script and validate it is working. I have done this too many times and it's a royal pain, BUT it’s the cost of doing inefficient business when for whatever reason when someone claims that a "legacy" system cannot be replaced, just move it.

Lastly, I have had Windows updates kill "legacy" programs which needs to be mentioned to the person, group, or company with the requirements that IF an update kills the application then you cannot guarantee that you can roll back the update because sometimes you can't so while the solution may bridge the transition today long term it needs to be properly addressed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.