Jill D. Headen

Colorado Technical University

CS630-1502B-01 - Modern Operating Systems

Proprietary Operating System for State Government Software Development and Implementation

Dr. Jesús Borrego

June 21, 2015

 

 

 


 

Table of Contents

1       Project Outline. 3

1.1        Brief Description of Enterprise. 3

1.2        Summary of Current System.. 4

2       Operating System Processor and Core (Week 1) 5

2.1        Requirements. 5

3       Scheduling Algorithms (Week 2) 7

4       OS Concurrency Mechanism (Week 3) 9

5       OS Security Risks and Mitigation Strategy (Week 4) 10

6       Future Considerations Using Emerging Technology (Week 5) 15

7       Appendix: Project Approval 19

 

 


 

1        Project Outline

1.1       Brief Description of Enterprise

The State of Washington is currently employing IBM to create and maintain the software system used to administer benefits (such as medical and financial) to Washington residents.

This system has an online component used by field agents, a data warehouse to store client information, an eligibility rules engine, a virtual network so that any State employee or IBM employee can access their work machines remotely, development environments for creating and testing new versions of the software (in addition to the production environment), development tools, and all of the usual applications used to run a typical business: email, word processors, spreadsheets, etc.

In addition to this, both the State and IBM must comply with Federal guidelines concerning the protection of sensitive client information, such as Private Personal Information (PPI) or Health Insurance Portability and Accountability Act (HIPAA) data.

1.2       Summary of Current System

The current system has been designed, built, and maintained by IBM for several decades. State employees in charge of the project rely on IBM employees to handle pretty much all of the technical work. For example, high-ranking State managers hire new State employees and approve their access to the system – and then an IBM employee does the actual work of granting the permission. IBM developers take software requirements from State business analysts and implement them in the system, then State software testers make sure the changes are correct.

 

2        Operating System Processor and Core (Week 1)

The current system is distributed among a collection of clustered servers running different operating systems loosely coupled together. If the operating system were upgraded to optimize the use of a multi-processor, multi-core configuration, then the entire system (as Stallings says in Operating Systems Internal and Design Principles) would benefit in the areas of Performance, Availability, Incremental Growth, and Scaling because the processors and their programs could share the work at a more integrated level (Stallings, 2012.)

To upgrade the processors and cores, all resources they will be using should be evaluated for compatibility, and the same vendor should be used so that hot-swapping will not result in potential performance loss (Siebert, 2009).

In this particular case, I think that several duplicate machines should be purchased so that can be configured together, tested, documented, and distributed to backup sites around the US for disaster recovery purposes. These machines should be fully operational and functioning perfectly before the system switches over to run on them. This should probably be done over an extended State or Federal holiday weekend to minimize disruption.

2.1       Requirements

For security reasons, the operating system should completely encapsulate the different areas of memory used to store client data from the areas used to store third-party business applications. All test information in the development and test environments should be clearly falsified data used for testing purposes. The OS should be able to detect an attempt from any internal or external source to access the live client database, or any materials created with this information. Even an attempt to use a “screenshot” function on a machine that is able to access live data should be recorded and reported to the security department.

The operating system should keep the Development, Testing, and Production environments parallel to each other and completely isolated from each other. The Development and Test environments should be unable to access live Production information, and attempts to do so should be reported.

The steps needed to “back out” a change to the system should be clear, along with the steps needed to verify that the system is operating correctly. The OS should also be evaluated from time to time to make sure that the configurations (such as the processor scheduling algorithm choice) are optimal.

The OS should accommodate Disaster Recovery, hardware replacement/upgrades, and future expansion. Having identical processors and cores on hand for replacements as needed both in the server room and at the backup facilities is recommended.

The OS should facilitate the end-of-life cycle for servers that have stored sensitive data.

The steps to terminate access to the system for former employees should be clear and quick to implement, and the OS should ensure that there are no “back door” access points to client data.

The OS should enthusiastically support encryption and accommodate the implementation of new encryption schemas as they are invented and adopted by the enterprise.

3        Scheduling Algorithms (Week 2)

There should be two clusters of machines: one to host the Development and Test environments along with the email server and a cloud system for hosting employees’ virtual machines.

There will be a virtual environment so that employees of either the State or IBM can connect remotely (from home or from meetings rooms at the office) to their virtual desktop computers and do regular business things like write with word processors, create spreadsheets, and check email. The cluster hosting these virtual environments can also host the virtual Development and Test environments. This cluster could be scheduled with each independently parallel virtual processor handling user-level threads in a Round Robin algorithm. Independent users starting up independent processes would benefit most from a system configured to maximize timesharing (Tanenbaum, 2008). A general “Load Sharing” approach would work well in this environment. The Stallings text tells us “… load sharing is one of the most commonly used schemes in multiprocessors (Stallings 2012).”

As mentioned before, the development team and the test team will have virtual development areas and virtual test areas set up to mimic the Production server as closely as possible, but without live data. One benefit of this scenario is that the Production environment can be kept isolated from the Development and Test environments for security reasons, but there is a challenge in the potential for the Production environment to have some subtle difference that might affect performance or security.

The Development and Test environments will have dedicated processors to handle kernel-based threads, because the users in this environment are all working on the same application and requests may be grouped together. System calls to compile the software should be grouped together because developers and testers can only do their work on the latest version of the system compilation requests to be processed might impede the development effort.

The Production environment will not be virtualized. Security and stability are the key requirements for this area, so multiple cores operating with a Gang Scheduling approach may be the best answer. Because the Production environment is a dedicated cluster, allocating certain processors for certain tasks (such as batch processing) is possible without causing hang-ups to other parts of the system. (Stallings 2012).

 

4        OS Concurrency Mechanism (Week 3)

Concurrency, synchronization, and communication in a distributed computing environment (such as the one I am proposing) can be managed with active objects, as described by Gullekson. Each active object has two ports: one for receiving messages from the operating system telling it to do some work, and another one for telling the operating system that the work is complete. The active object can contain encapsulated data and passive objects that do the actual work. The active object also contains an encapsulated execution thread so that the active object can process the work in a straightforward manner until it is complete.

Because of their object-oriented concept, an active object (or a collection of connected active objects) can be created specifically to handle deadlock or resource conflict problems. Active objects can contain both the data they need and the execution thread. If nothing else can access these things while the active object is using them, then there are no conflicts. Also, different configurations of active objects can be created to work together and with other parts of the system (Gullekson).

 

 

 

 

 

 

5        OS Security Risks and Mitigation Strategy (Week 4)

The areas of this operating system that should be evaluated for performing a risk assessment include:

Risk

Vulnerable Points

Relation to Operating System

Physical access points into the system

Š      Field agent terminals

Š      Office desktop machines

Š      Servers/terminals in the server room

As Josh Wepman states “Since operating system code and configuration files are installed on a system’s hard drive, an attacker with physical access to the system can easily modify, delete or steal critical files on a system.” (Wepman)

Therefore, the most critical area to protect from physical attack is the operating system on the hard drives of the servers that contain the databases of client information.

Malware

Š      Email server

Š      Office desktop machines

“Malware, short for malicious software, hijacks an operating system to perform some sort of task for an attacker.” (Wepman)

Example: if an attacker can get a virus or other malicious software onto the enterprise operating system, it could use the operating system’s own devices to harm or transmit client or employee data.


Commercial Operating Systems

Š      Office desktop machines

Š      Laptops used for remote access

Š      Virtual desktops running a commercial OS such as Windows or MacOS

The enterprise uses commercial operating systems in the day-to-day operation of the business, and these commercial operating systems are vast programs written and maintained by fallible human beings. Vulnerabilities happen.

Operating system manufacturers, such as Microsoft and Apple, frequently publish updates to the code, called patches, to fix these vulnerabilities and to ensure system stability.” (Wepman)

Authentication

Š      Desktop machines

Š      Remote access laptops

Š      Servers

Š      Email accounts

Cory Janssen recommends creating secure accounts that have only required privileges. (Janssen)

By this, he means that user accounts created in the system should only be allowed by the operating system to access the areas of the enterprise needed for their specific job role in order to accomplish work. For example, a business analyst who writes software requirements might need access to the development environment, but not to the client information in the production environment.

Network Access

Š      Field agent terminals

Š      Desktop machines

Š      Remote access laptops

Š      Enterprise servers

Š      Email servers

 

Janssen also recommends an operating system security approach that includes “scrutinizing all incoming and outgoing network traffic through a firewall.” (Janssen)

 

Five risks that pertain to my selected operating system include:

1.     Physical attack: Because this is a government enterprise, both the office and where the servers are housed are at increased risk of physical and terrorist attacks, including “active shooter” situations and attempts by bad people to “piggyback” into our office behind well-meaning employees. This would affect the operating system if a bad person got into the building and forced an employee to log into the system with their valid credentials. Then, the attacker would be able to use the operating system to harm or transmit client or employee data.

2.     Malware: malicious software could be uploaded via email attachment, USB device, floppy disk, or via unauthorized access to the system. Anywhere the operating system can be accessed is a potential vulnerable area.

3.     Commercial operating systems: it is common knowledge that the commercial operating systems used in the virtual desktop environments, desktop machines, and laptops of remote users have vulnerabilities that must be found and patched. Otherwise, the security holes in unpatched operating systems could be exploited to reach the enterprise operating system as a whole.

4.     Authentication: although a user hired and granted access to the enterprise is assumed benign, it is better to give users the lowest level of access to parts of the system required for them to accomplish work. If a user does not need production environment client information, then is it better that they cannot access that area.

5.     Firewall: a firewall can protect the operating system by preventing access from outside and preventing access to dangerous websites from within the system.

Risk mitigation approaches for each risk

1.     Physical attack: Closely monitored access points into the building, employee training, cameras, and implementation of a “panic button” password employees could enter if someone were forcing them to log on against their will. The panic button would cause the system to boot into a seemingly normal desktop system, but all information displayed would be bogus and there would be a silent alarm raised. If the attempt happened on a laptop, the laptop’s camera would be activated to capture the image of the attacker.

2.     After the first point of defense (preventing physical access to the operating system), malware must be searched for and combatted with dependable, current virus detection software.

3.     Commercial operating system patches must be downloaded and a[applied on a regular basis.

4.     Restrict user authorization to the lowest level required for them to do their work. Track all accounts that access sensitive areas of the enterprise.

5.     A firewall between the enterprise operating system and the outside world is a good first line of defense.

 

 

 

6        Future Considerations Using Emerging Technology (Week 5)

In the future, more (if not all) of the enterprise might be run on a cloud system owned and maintained by a trusted third party, such as IBM. Among other considerations, such as legal constraints about where certain types of data can be physically hosted, Vic Winkler states: “The cloud provider market is expanding, but there are still only a limited number of players that can offer large-scale application and data hosting.” (Winkler). IBM is one of those large-scale companies. Benefits include reduced hardware costs and reduced effort to keep state employees up-to-date on the latest versions of software (Strickland).

Architecturally, according to Strickland, if IBM’s cloud is deployed in a grid system, “then the client could take advantage of the entire network's processing power. …On a grid computing system, the client could send the calculation to the cloud for processing. The cloud system would tap into the processing power of all available computers on the back end, significantly speeding up the calculation” (Strickland). In theory, this could reduce wait times for the information needed to process client data for system eligibility changes and increase accuracy within the system.

Increased virtualization is another consideration. If the IBM cloud were eventually deemed suitable for hosting sensitive client data, then it stands to reason that the field agent tasks currently performed via mainframe terminals could be done on less expensive, modern desktop systems (or possibly on embedded systems) connected to virtual desktops systems. Office personnel (such as myself) would no longer have to perform the multiple reboots to needed to process system upgrade patches, which sometimes take up to 45 minutes a day, 3 or more days a week.

Another innovation could be the use of “bring your own device” (BYOD) capabilities by the field agents. If agents could use mobile devices to register clients for state benefits, then they could go to areas of need, such as the landslide in Oso, WA on March 22, 2014. The benefits of this would be faster and more accurate capturing of data, even if the local field office had been destroyed in the landslide. Given Washington State’s history of volcanic eruption, the more mobile its state services are, the better.

 


 

References

Gullekson, G. Designing for Concurrency and Distribution with Rational Rose RealTime. Rational Software White Paper. Retrieved from: http://www.ibm.com/developerworks/rational/library/content/03July/0000/0598/PS-0598.pdf

Janssen, C. (n.d.). Operating System Security (OS Security). Techopedia. Retrieved from: http://www.techopedia.com/definition/24774/operating-system-security-os-security

Kaiser, R. (2015.) Scheduling virtual machines in real time embedded systems. Industrial Ethernet Book Issue 62 / 52. Retrieved from: http://www.iebmedia.com/index.php?id=7597&parentid=63&themeid=255&hft=62&showdetail=true&bb=1

Schramm, N. & Norbert, A. (2008, November). Concurrent Programming Method for Embedded Systems. 9th International Symposium of Hungarian Researchers on Computational Intelligence and Informatics. Retrieved from: http://uni-obuda.hu/conferences/cinti2008/33_cinti2008_submission.pdf

Silberschatz, A. & Galvin, P. (1999). Operating System Concepts, Fifth Edition. New York, NY: John Wiley & Sons.

Siebert, E. (2009, April). Selecting CPU, processors and memory for virtualized environments. Retrieved from: http://searchservervirtualization.techtarget.com/tip/Selecting-CPU-processors-and-memory-for-virtualized-environments

Stallings, W. (2009). Operating systems: Internals and design principles (6th ed.). Pearson Education International. Retrieved from http://www.informatik.unikiel.de/fileadmin/arbeitsgruppen/comsys/files/ws0809/05_concurrency.pdf

Strickland. J. (n.d.). How Cloud Computing Works. How Stuff Works. Retrieved from: http://computer.howstuffworks.com/cloud-computing/cloud-computing.htm

Tanenbaum, A. (2008). Modern Operating Systems, Third Edition (pp. 543-544). Upper Saddle River, NJ: Pearson Prentice Hall.

Winkler, V. (2011). Cloud Computing: Data Privacy in the Cloud. TechNet Magazine. Published August 2012. Retrieved from: https://technet.microsoft.com/en-us/magazine/jj554305.aspx

Wepman, J. (n.d.). Operating System Security Issues. eHow.com. Retrieved from: http://www.ehow.com/list_6691860_operating-system-security-issues.html

 

 

 


 

7        Appendix: Project Approval

Enterprise Proposal

Jill Headen

Sun 5/31/2015 8:42 AM

Good morning, Dr. Borrego: Here is my updated Enterprise proposal. I was initially worried about writing something that might come across as critical of IBM's practices, but the more I learn about all this, the more I like how things are set up.

Jesus Borrego <JBorrego@faculty.ctuonline.edu>

Tue 5/26/2015 3:06 PM

To: Jill Headen;

You replied on 5/31/2015 8:42 AM.


Project approved as proposed:
The State of Washington is currently employing IBM  to create and maintain the software system used to administer benefits (such as medical and financial) to Washington residents.

This system has an online component used by field agents, a data warehouse to store client information, eligibility rules engines, a virtual network so that any State or IBM worker can access their work machines remotely, development environments for creating and testing new versions of the software (in addition to the production environment), development tools, and all of the usual applications used to run a typical business: email, word processors, spreadsheets, etc. In addition to this, both the State and IBM must comply with Federal guidelines concerning the protection of sensitive client information, such as Private Personal Information (PPI) or Health Insurance Portability and Accountability Act (HIPAA) data.

The current system has been designed, built, and maintained by IBM for several decades. State employees in charge of the project rely on IBM contractors to handle pretty much all of the technical work. For example, high-ranking State managers hire new State employees and approve their access to the system – and then an IBM contractor does the actual work of granting the permission. IBM developers take software requirements from State Business Analysts and implement them in the system, then State software testers make sure the changes are correct.
Hypothetically, this puts a State government almost completely at the mercy of a private corporation. If the president of IBM decides to take her company out of the software business, the State of Washington is going to have to scramble to find another company to handle their IT needs.

For security reasons, the operating system should completely encapsulate the different areas of memory used to store client data from the third-party applications used to handle the business needs.  The operating system should keep the Development, Testing, and Production environments parallel to each other and completely isolated from each other.

The steps needed to “back out” a change to the system should be clear, along with the steps needed to verify that the system is operating correctly. The OS should accommodate Disaster Recovery, hardware replacement/upgrades, and future expansion.

Note: Federal law currently prohibits the storage of PPI/HIPAA client data on a “cloud” system. (Source is document IRS 1075.)