Tag Archives: Windows 2008 Server end of life

The Costs of Doing Application Life Cycle Management Not Right

12 May 2019

For the following text, let us assume that we created a fictional application named Our Awesome App (OAA) on the basis of the Microsoft technology stack. OOA runs on top of the Windows 2008 R2 Server OS. Microsoft stops the support for this version in January 2020, thus we may have some migrations to do.

What is application lifecycle management?

Application lifecycle management (ALM) is a continuous process of managing the life of an application through governance, development and maintenance.”(1)

I prefer this brief definition of ALM of 2010 although the current Wikipedia definition(2) is more comprehensive.

It is the restriction to applications that creates the trouble in both definitions because applications are bound to a Web or Technology Stack.(3)

Technology Stack

Technology Stack

Each product in the technology stack has a life cycle, usually independent of the life cycle of the other layers and of OAA. With this, application life cycle management cannot be considered independently from the technology stack. Even if no development takes place on the application layer, changes in the technology stack might demand changes in the application.

Usually, ALM deals with Layers 1 to 4 of the technology stack. Neither the database nor the server is in focus of ALM. For the LAMP (Linux, Apache, MySQL, PHP) stack, this creates no big trouble because the middleware (Apache) and the database (MySQL) are largely immune to changes in the Linux OS.

Microsoft Technology Stack

Microsoft Technology Stack

But in the case of OAA we face some trouble because the Internet Information Server (IIS 7.5) is a component of the Windows 2008 R2 Server OS. A change in the server OS might have a great impact on the application.

What’s the trouble with the Windows 2008 R2 Server end of life?

Every day new vulnerabilities in IT products are published. All layers in the technology stack are impacted. The Windows update service takes care that newly detected vulnerabilities on layers 2 – 5 are automatically patched because we built OAA on top of the Microsoft technology stack. So, the application manager has to deal only with vulnerabilities in OAA.

Microsoft provides no longer patches once a product goes beyond the end of its life. But new vulnerabilities for such products are still discovered and published. This increases the number of unpatched vulnerabilities on the server and middleware layer. With this, the security level of the whole network is lowered because unpatched Windows systems facilitate, in the worst case, the propagation of malware like WannaCry or NotPetya.

What’s the trouble with application life cycle management?

ALM is a tedious and costly task. Getting ALM right requires continuous study of the life cycle of all products on the technology stack and continuous planning, development, integration and testing across all layers of the application stack. Therefore, application managers care often only of the first layer. Developers are responsible for the second, the third and to some extend also for the fourth layer. Someone from IT operations takes care of layers 4 to 6, but no one cares of the entire technology stack.

Eventually, someone realises that some hundred Windows 2008 R2 Servers are still in operation, and only few months left for migration. Migration of applications including the middleware is a lengthy process. Thus, it is obvious to spend some money for extended support, just to buy time to get the migrations done.

What are the costs for extended support?

For the following calculation, let us assume that 20 Windows 2008 R2 servers running the Datacenter Edition and 400 servers running the Standard Edition are still in use. The price for extended on-premise support is at 75% annually of the full license price of the latest Windows server version, provided either software assurance or a subscription is available.(4) Let us assume that the IT team works hard on the migrations and the number of servers to go is reduced every year.

A brief sample calculation based on the regular price sheet(5) shows that a large amount of money is spent just for some security patches.

Sample Windows 2008 Server Extended Support Calculation

Sample Windows 2008 Server Extended Support Calculation

It is very important to note that these expenses are unplanned costs. They reduce the company’s earnings. Fortunately, this cost can be avoided if ALM is extended to the whole technology stack.

How to tackle the application life cycle management challenge?

(1) Move the accountability for ALM to the board.

The board is accountable for revenues and earnings. Since unplanned expenses for ALM lower the earnings the CFO should take control.

(2) Embed ALM in your daily business.

ALM is no project. It is a continuous activity that requires coordinated planning across all stakeholders in the business and IT groups. The application development budget should be extended to cover cost caused by changes in the technology stack.

(3) Start early, at least 2 years before the end of life of a product.

Minimize down times to keep the users happy.

(4) Set up and maintain an asset repository.

The asset repository should provide details on the technology stack of each application and the interfaces between applications. Is the repository up-to-date it takes only few minutes to become an idea of the effort related with the next life cycle change.

(5) Develop a concept for applications that cannot be migrated.

In some application areas, such as manufacturing, it is often not possible to migrate to newer versions in due time, for example due to technical restrictions by the vendor. For these applications, concepts must be developed to ensure secure operations beyond the end of life of tech stack components.

(6) Develop an application design guide to simplify ALM and security operations.

Applications should be developed such that they are to a large extent immune against changes in the technology stack. Procurement should take care that off-the-shelf solutions comply to the guidelines.

(7) Foster the change towards DevOps in the IT organisation.

DevOps teams should be responsible for the entire technology stack. At least the testing process should be automated. This will speed-up the roll out of security patches as well.

By the way, Microsoft announced the end of life of Windows 2012 R2 Server for 2023. This change will also affect the whole technology stack, thus start at least in 2021 with preparations.

Have a great week.


References

1. Appelo J. Agile Application Lifecycle Management (ALM) [Internet]. Business presented at; 2010 Nov 22 [cited 2019 May 7]. Available from: https://de.slideshare.net/jurgenappelo/agile-alm

2. Application lifecycle management. In: Wikipedia [Internet]. 2019 [cited 2019 May 7]. Available from: https://en.wikipedia.org/w/index.php?title=Application_lifecycle_management&oldid=895749396

3. Rouse M. What is Web stack? – Definition from WhatIs.com [Internet]. WhatIs.com. 2012 [cited 2019 Apr 29]. Available from: https://whatis.techtarget.com/definition/Web-stack

4. Microsoft. Extended Security Updates for Windows Server 2008 and SQL Server 2008 End of Service FAQ [Internet]. 2019. Available from: https://download.microsoft.com/download/C/8/5/C851D4E2-ED1F-4F56-AEC0-1561D85AB489/Extended_Security_Updates_for_Windows_Server_2008_and_SQL_Server_2008_End_of_Service_FAQ.pdf

5. Microsoft. Windows Server 2019 Licensing & Pricing | Microsoft [Internet]. Microsoft Cloud-Platform – US (English). [cited 2019 Apr 29]. Available from: https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing

Windows 2008 Server End of Life: The best chance to move to the cloud

30 June 2018

Windows 2008 Server End of Life is near. Within the next months many companies are busy with the replacement of Windows 2008 based infrastructure and application servers to avoid the next Wannacry or NotPetya.

It appears to me that this is the best opportunity to migrate at least application servers to the cloud. And, in the best case, to get rid of the servers at all by transforming the application to SAAS. If technical or the organizational limitations do not allow this at least the transformation to PAAS and IAAS should be considered.

What stops us from doing this? Very often it is the fear of loss of access to critical business data or the fear of loss of the data at all. At least in the latter case technical protection measures can be applied to mitigate this issue.

Transparent database encryption

Transparent database encryption (TDE) is often the matter of choice. All encryption is performed transparently by the database service, with no impact on the application and the users because only the database files or critical attributes in tables are encrypted. User interaction is required only during database startup to activate the encryption engine.

Unfortunately, TDE provides only encryption at rest. Thus TDE stops infrastructure admins from using unauthorized copies of a database or a virtual database server because they cannot activate the encryption engine. Once the database is started all users and database administrators have access.

Application level encryption

With Application level encryption (ALE) all encryption is performed by the application. Data is encrypted when entered in or retrieved through the application. Thus data is encrypted during transfer and at rest.

As long as the access is not routed through the application server the data are accessible for no one. Even infrastructure or database admins are barred unless they have access to the encryption key.

The security problem is shifted towards that of operational security of the application server. A solution to this problem could be to encrypt the data in the database with a key that is encrypted against the users access keys. This ensures that the encrypted data cannot be decrypted without access to at least one users key.

The remaining risk is that an attacker reads the keys or the plain text data from the process memory of the application service.

The effort to implement application level encryption is high because the application has to be changed. In addition, a key infrastructure must be set up to avoid data loss in the case a user key is e.g. inaccessible. But the gain in information and operational security is high.

The pros and cons of the encryption concepts in summary.

Table 1: Database Encryption Concepts Summary

Table 1: Database Encryption Concepts Summary

With Application Level Encryption, outsourcing or cloud adoption is made easy.

Have a good weekend.