Technical Architect JAVA

Technical Architect for Java upgrade

The Technical Architect will define the approach for the Java client upgrade project.

Background:

The security of its IT infrastructure is a key concern to the company. Embedded in the larger Cyber Defense Security Program, a project has been started up to further reduce the company's exposure to Java Runtime environment (JRE) related security risks.
By the end of the project, we want to have removed the outdated JRE versions from its clients, as defined by its security policies. Exceptions should be clearly documented and the Software Intake and the Exception Handling Processes should be properly triggered.
The current opening has been defined for the duration of the project definition phase after which we will evaluate the need for extension of the mission.

Responsibilities:
*Document the architecture aspects required to pass the "Go-for-Execution" project milestone
*Collect inputs
oRegarding security: from Security Governance as well as from Security Officers
oRegarding applications and user impact: Key Users, Application Owners and Data Managers of the different divisions
oRegarding IT: Packaging & distribution, Helpdesk, …
*Consolidate the collected information into a coherent approach (communication/ migration waves/exceptions, …) / scope / schedule in collaboration with the project manager

*To be able to recommend the approach, the technical architect performs a study on the upgrade of JRE on the clients:

oMake an inventory of the blocking factors, preventing the company from simply removing the old JRE version from and installing the latest version for the full installed client computers base, like p.e.
Technical
*Critical 3rd party applications not compatible with the latest JRE version
*For custom development no general solution for application signing is currently available
Organizational:
*Incomplete inventory of applications with application owners and key users
oPinpoint out which are the incurred the security risks, related to JRE in the existing landscape, starting from a recent preliminary study
Categorization of cases
*Native browser JRE (exposed to the Internet)
*Applications making use of the native browser
*Embedded JRE versions in applications and platforms
*Including the applications used by development and support teams
*Challenge the current viewpoint that JRE security risks incurred at the server side are relatively small
*Determine which generic cases are (not) compliant with the security policies in place at the company
Remark: The parameters for the categorization are not purely technical, p.e.: cost, user impact and size of the user base can also be considered
Define the project's impact on the community of a generic application: from development (package or custom) till end-users and support

To verify some assumptions, it might be needed to perform technical tests or contact vendors.
oDefinition of the risk strategy and mitigation approach
Investigate and validate alternative risk responses (avoidance / mitigation, …)
Recommend a risk approach per category
Remark: the mitigations can go well beyond the pure JAVA context, like working out a solution for application signing through a certificate
oDefine the project approach for implementation and migration
Determine the technical deliverables like: required JRE packages, required mitigation infrastructure …
Define the roles needed for the execution phase
Define the distribution strategy:
*allow users / groups to test and self-enrol the new version
*forced installation (with possibility to delay)
Schedule: Definition of the waves such that risks are minimized
Define a roll-back strategy
Catch and analyse the risks related with the project approach:
*Only limited testing is considered
Define the solution for the reporting of project's progress
Indicate what is out of scope of the solution
*Document the "incompliances", already encountered in this phase

Skills & Previous Experience
*The Security Architect should have a firm background on JRE, JRE evolution and versions
oJRE versions and the new and deprecated features in v1.7 and v1.8
oPrevious experience of JRE upgrades in large environments
*Good view on security risks related to JRE and on the possible mitigating controls
*Can work independently: takes initiatives and is persistent in chasing results
*Good communication skills: ideally in English, Dutch and French are an asset