This tutorial may need a fair amount of additional work yet, in order to communicate what is needed and to do so in something resembling a streamlined manner unlike what this sentence seems to do.
Update: This may or may not be in much better shape now. There is some older text near the bottom.
- [#tutgoal]: The Goal
The goal of this tutorial is to provide directions to obtain, and then to maintain, a maximum amount of trustworthiness. This desired goal isn't so much about helping a person to trust a machine. The desired benefit is not obtained by being able to naively convince one's own self to blindly trust a machine (no matter how badly that machine may already be infected with malware). Rather, the focus is about maximizing the amount of good reason why a machine (or service or network) is as worthy as possible of any particular amount of trust that it may be given.
- [#howtrust]: The Methods Used To Get A Trustworthy Network
One of the two key methods of this guide is to start with the most trustworthy code possible, and to spread the state of being as trustworthy as possible.
However, all that gained trust quickly becomes useless if the trust is compromised shortly after it is gained. Therefore, the other key moethod is to set up strong barriers that isolates distrust. For instance, if a computer on a network is distrusted, otherh computers may still be trustworthy if they had protection that was suitable to prevent them from also being untrustworthy.
- [#prptsrtd]: Startup/Preparation
Start with a machine which is sufficiently isolated. The machine should be isolated from Internet attacks by being offline or by being isolated by a trustworthy firewall.
Also start with trusted code. Although this absolutely essential step may seem obvious, it is more true than what many people realize or implement. For some reasons described by the hidden malware section, a machine is not going to be trusted just because it has anti-virus software claiming that it is up to date, even if the anti-virus software comes from a well-known name.
The plan is going to be to wipe the machine. This guide is not going to worry so much about trying to check firmware, which is admittedly imperfect security. Instead, this guide is going to recommend backing up any sort of data needed on a machine, and then simply wiping a hard drive with all zeroes.
- Wiping a machine (overview/background)
Actually, zero'ing the hard drive is a process that can take quite a bit of time, and is fairly optional as long as one makes sure that all pre-existing code is eliminated from any sectors before it is executed. However, zeroing the hard drive is the easy option. On an x86 machine using a standard BIOS, and assuming all the operating systems used will use a standard operating system procedure, this may done by not using any pre-existing partitions, overwriting the MBR, re-creating new partitions, formatting all partitions before they are used, and then only storing data in such partitions. For home use, those who are familiar with such processes may save time, such as hours or even days, by being careful to follow those steps instead of zeroing the hard drive. For use by a business, or an organization such as a classroom setting, it may be easier to document what was implemented by just having an activity of zeroing out the hard drive.
Assuming that the implementation of zeroing out the hard drive is complete, this will disable any sort of malware that may have been on the drive (assuming the malware didn't first get copied somewhere else, like into RAM). Even if malware could be retrieved using advanced hardware (see the section of recoverability of data that's been wiped), the chances of such a thing happening seem minute enough that such chances are not a worthwhile concern. The chances would be lower than that of other threats (such as somebody accessing the hard drive when it isn't in use, and re-infecting the drive).
- Wiping a machine (technical details)
- Identify how many hard drives there are in the system. Before destroying any data, be sure to back up any data which is needed! Then, see the section on wiping media.
- Choosing operating system media
This includes choosing an operating system.
Since there are some various opinions (some with good reasons and others with less good reasons), to keep this guide rather neutral, details are not provided. Basically, (at this time) this guide does not provide much details in the way of making such important decisions. (Naturally, if performing this task as part of an organized activity, the recommended course of action may be to follow guidelines provided for those who participate in the organization's activity.) Naturally, the trustworthiness of the end result may be affected by poor decisions (such as using custom-burned media that comes from data obtained from untrustworthy sources on the Internet).
- [#nottlsec]: No total security
(This section is informational/background/overview, and does not include actions that need to be taken.)
Security is not total: imperfection is required. The reasons why are discussed in a separate section, no total security. (Reading that section is intended to be a part of this guide. That section used to be part of this guide, but it was moved to a separate section since it was suitably large and separatable.)
- Making the machine useful
At this point, if the machine is prepared, it should be fairly trusted: Presumably it has no malware on the drives, and it has no network access.
Make sure there's no hidden USB sticks that the computer might boot off of. (Such a thing could reduce the trustworthiness of the system.)
The next step will be to Install the operating system. If installing from a CD, continue to deprive the computer of any network access. If installing from a network, realize that the computer's trustworthiness may be reduced if a successful network attack happens. The degree of risk may correspond to factors such as how good the network defences, such as firewalls, really are.
As much as possible without network access, set up the operating system including hardening Administrator accounts, etc.
Also get service packs, Anti-Virus software, and operating system patches installed, without network access, if that is a convenient possibility. If it isn't convenient, weigh in the risks of threats and how much potential reduction there is to the overall trustworthiness of the desired end result. If network access is needed, see if the software can be obtained from a trusted machine/network. For some operating systems, it would be considered foolhardily compromising to be connecting the system to the Internet without a firewall, drastically reducing any reasoning to be considering the system to be trustworthy.
In general, in an ideal setup, it is only after the system is secured as much as possible should one consider adding other services.
- Keeping the system secure
Keep distrust isolated.
Have a good disaster recovery plan. (If a machine can be re-installed quickly, there will be less hesitation to do so in the light of problems.) See about how to utilize automatic updates of the operating system: Even if there isn't the desire to apply such updates automatically, it may be worthwhile to download or at least receive information about such updates as they become available. Implement additional security detection measures such as file integrity checks.
Spread trust by improving other systems on the network. If they are less likely to be hostile, that may reduce internal threat which may be a good and positive thing.
OLD TEXTThis is done by improving trust as much as possible, lowering trust only as much as needed to accomplish useful tasks, isolating distrust, checking. certain amounts of trust. the worthiness as much reason to find a computer to be worthy of being trusted and maintain as much reason to trust a machine as possible. This doesn't mean naively trusting a machine no matter how badly it may already be infected with malware. The focus isn't necessarily on having trust, but on maximizing the amount of good reason why a machine is worthy of being trusted to a high degree (including raising that degree that the machine may be worthy of). , and maximizing the degree of trust a certain amount of trust. having as much reason to trust. on having as much reason to have that trust. as possible to have and maintain The goal of this guide is to provide some directions that will help a technician to be able to improve how trustworthy a machine may be and to be able to have as much reason as possible to keep having that machine be as trustworthy keep as much reason to that trust as much as possible. limit the losses of distrust and to improve the trustworthiness of a machine be able to trust a machine to a greater degree.
The key step is to isolate distrust, including potential distrust in case actual distrust ends up occurring. In addition to preventing distrust as much as possible, isolate the consequences that occurs if certain trust becomes compromised (or is already compromised).
Certain things can lower the amount of trust on a machine. One example is finding out that the machine is behaving undesirably because it is clearly taken over by malware. Another example of an action that may lower how much a machine is trusted is to provide an additional, perhaps less trustworthy, person to have access to the machine.
Eliminating distrust may sound desirable, but there are often problems with that goal.
Status: This guide is not yet complete.
The goals of this guide are to get all machines on a network so that they are running trusted code, and to have appropriate barriers The goal of this guide is to turn all machines on a network into a machine that has trusted code, to be able to rapidly turn a machine with less trusted code into a machine that has trusted code, and the ability to test trust.
- A server which has never had a problem been using trusted software Machines which have been installed from trusted code
The key step is to isolate distrust, including potential distrust in case actual distrust ends up occurring. In addition to preventing distrust as much as possible, isolate the consequences that occurs if certain trust becomes compromised (or is already compromised).
For example, a workstation may rely on automatic addressing, trusting that proper addresses will be handed out as needed. What happens if the server stops working? For example, perhaps the server is rebooted. As that server restarts, the server cannot help other workstations. This way, any contamination of trust will be more likely to be isolated. That will make clean-up easier: for some machines the entire clean-up process may consist of thinking about whether the machine would have been exposed to the same troubles. If not, the machine is already cleaned up.
This allows for some potential advantages. Any problems that eventually exist may be able to be localized into an isolated area, which will allow for easier clean-up. For example, if it is discovered that somebody downloaded a virus onto one machine one machine If it is detected that somebody vandalized a web server, way, any problems that may exist can be localized into an isolated area, which will allow for e
By being an isolationist, problems that exist can be localized and more easily replaced. For example, any problems that do occur Keeping everything completely trusted may initially sound like a worthy goal, although that is easier said than done. For example, the IT staff members of an organization may want to implement a policy that says that nobody is allowed to install software that hasn't been approved by the IT department. The key problem with such a policy is that somebody may be interested in installing software. That person may find the approval process to be an annoyance, and may decide to not follow those rules.
This guide is about taking two significant steps in order to have a trusted network. These steps are significant, meaning that they are not necessarily going to be small, simple, nor fast, and may not be easy. However, they are the way to have the most trusted computer network(s) in any currently-known galaxy (and to keep them trusted).
- The goal
The goal of this section is to describe how to ensure there's a secure setup and to keep things secure so that unauthorized activity is not occurring. Specifically, this text describes how to convert a computer network from a state of distrust (such as if there is known malware on the machine) or unknown trust (such as if one or more computer support staff start to support an already existing network) to a state where earlier compromises are not affecting critical services, and a state where each service is as secure as possible.
- Physical security is impactful
Physical security is a whole 'nother realm, and a lapse in physical security can defeat many security measures, including any of the network security measures in this section. (This is backed up by some third parties. For example, OpenBSD FAQ 8.1: Lost password describes a method to reset a system administrator's password and has a section called “That looked too easy”. The counter-arguments are given. Seth Fogie's “A Student-Hacker Showdown at the Collegiate Cyber Defense Competition (Page 8 of 9: section called “Day Three”)) documents when a system protected by a BIOS password was bypassed by creating an electrical short which is the proper way to reset the information in the CMOS. This was done even though the system was in a locked room (as described further on the web page).
However, sufficient physical security may require a separate study all to itself, and many times a lot of a company's physical security aspects may be managed by a specialized department. (For large enough organizations, this department may be called a “security” department. For smaller organizations, such a role might be handled by a “facilities” department that also does things like HVAC maintenance.) Although a computer network engineer may be involved with attaching security equipment to a network, this section is more focused on certain configuration aspects which many security personnel would find a computer expert to be more appropriate to oversee.
Therefore, this text isn't focused on the very important portion of security which is making sure physical security is in good order.
- The impossibility of total security
The concept of information security is often described as threat mitigation: handling and controlling potential threats so that they do not end becoming something that successfully accesses data in unwanted ways. Keep in mind that this isn't strictly limited to network-based attacks such as the negative effects of people spreading malware on the Internet. For instance, to keep information secure from the threat of fire, it is recommended to always having at least one copy of the data in at least two separate geographic locations. Unless one can absolutely prevent, with 100% certainty, all possible threats, then the information security is less than total security. Some threats are not 100% managable. For instance, threats that are generally beyond the control of any typical computer support company could include simultaneous natural disasters. (Such unpleasant events have been known to be referred to as an “act of God”, even by secular (non-religious) institutions.) Another example would be artificial devastation that is so significant that it is widely referred to as an “act of war”.
As an organization becomes larger and larger, the possibility of internal attacks, very possibly in the form of personally-profitable fraud (but perhaps in another form such as sabotage), becomes an increased possibility.
Any organization where multiple people have physical access to the hardware, including a home, leaves the computer potentially available to attacks involving insufficient physical security. Since every person needs to sleep, no single person can watch over even a single computer all the time.
- Invade, only as desired
Clearly, it is generally undesirable in society for people to be performing unauthorized actions. Be certain that proper authorization is clearly determined. This may involve communicating with the owner (or appropriate representative(s)) of the computer(s). Realize what systems may be controlled and in what ways.
Those who are just working at home and only working on equipment that they own may be best served (time-wise) by skipping this section. For others, particularly those who are working on equipment (whether computers or other networking equipment) which may not belong to them, in order to learn more, here are some hypothetical examples of potential situations where authorization may prevent something from being done.
- Non-local authorization
- The potential problem
- Any equipment that belongs to another organization is something that there may be limited or no access to. Typical examples include suppliers of electrical power and wired technology that provides Internet connectity (and other services such as phone service). Granted, there are possibilities where those examples would not apply to a site (when the site generates its own electrical power, such as with solar panels, and uses a wireless method of Internet), but that wouldn't be nearly as common. External provides of services may provide some access to a remote machine. For example, a company that hosts a website on the Internet may intentionally allow access to modify the files that are used for providing the content of the website. This partial authorization does not imply that full access is authorized by the owners of the equipment.
- How to deal with the potential problem
Use common sense: In most cases a person or organization probably does not own a service provider such as an Internet webhosting company, a phone company, or a cable company. Of course there may be exceptions, such as if the organization being helped is, in fact, a phone company. Even in such cases, there may be equipment that belongs to a different phone company. Realize that there are limits, and there many be many cases where fixing a problem may involve data or equipment that does not belong to the person who is requesting assistance. Equipment located on property that belongs to another organization is very likely equipment owned by someone other than the person or organization requesting assistance. There are many possible exceptions, but be sure to get clear and sensible answers before proceeding with changes.
Know that there are typically points of demarcation, also known as demark points, which help to specify what equipment is controllable by various people and/or organizations. Points of demarcation could half of a box of wiring equipment located outside of a building. If a person or organization is renting a building, a logical spot for a demarcation point may be the wall jacks, with the inside connector being owned and controlled by a different organization than the outside connector. In some cases, equipment located within the building may be owned by different organizations.
As generally safe practices, question whether proper authorization has been granted before trying to override restrictions such as dealing with a scenario where a password is unknown. (There are ways to reset many passwords. In many cases, a password that is unknown can be changed from an authorized account or through a procedure that resets a device to certain defaults. There may be other password reset procedures, such as (at least some versions of) MegaRAID Power Console Plus software which allows a password reset by moving a "raidpass.val” file. (This sort of password override is mentioned in the a manual which documents the override procedure and which instructs users to prevent such a thing by using security that affects access to that file). Similarly, determine whether proper authority is granted before trying to override other security restrictions, such as physically breaking a physical lock.
- Staff-owned equipment
As an example to be cautious of: do not assume that full control of every computer on a network is something that the organization has full rights to. If a personal laptop is attached to a network, and if this is authorized, removing data from that laptop may not be something that IT staff is permitted to do.
If a computer is using a professional version of Microsoft Windows and connects to the Microsoft Windows computer network, but that computer is accepting remote access/controls from a domain administrator, it may be that the system is intentionally not set up to allow the organization to fully control the computer. Determine why.
The easiest way to deal with a computer that isn't owned by an organization is to treat it similar to an attacker: Consider it to be unauthorized and deny it access to anything. Whether this is an acceptable course of action may vary based on specific circumstances. Such a policy typically eases the lives of the people who manage the security of a network, although management decisions may affect the implementability of such an approach.
- Multiple business owners
- The potential problem
A business may be owned by a partnership of multiple people. Perhaps a business is owned by one person, but then another person provides some money and it is then agreed that the second person is considered to own a third of the business. If business owners start to have disagreements over how things are run, one person may want some changes to be made to their computer equipment even if other business owners do not want those changes to be made. Ideally, a person who is asked to perform work on the computers will know, before such work is done, whether the information is actually authorized.
- Dealing with this situation
This example is rather difficult. If a person is overstepping their authority, such a problem may not be fully known to a computer support staff member. The best thing a computer support professional may be able to do is to get a request in writing. Have the person making the request agree, in writing, that they are authorized to make the request. Then if problems occur, that contract can be shown to legal authorities to show that the computer support personnel's actions were done in good faith. Such a contract could help move legal liability from the computer support personnel to the person who is overstepping authority.
- The disruptions of invasions
Many times, it is desired for the introduction of changes to an existing network to be minimally invasive. This suggests minimizing disruptive changes. However, there may be problems which it is desirable to invade certain situations so that disruptions do affect current or potential problems that exist. So, determine what the goals are.
An early step which should be done before making any change is to determine the expected impacts of expected changes. On a machine with a freshly installed operating system, changes to the network may initially be minimal. (Participation in converting network addresses from hardware addresses to and from logical addresses (IPv4 ARP/RARP), requests related to automatic addressing, and dynamic DNS updates are examples of some changes that may occur, but the impacts are likely to be minimal.) On an existing machine, further investigation may be warranted. Determine what network ports are listening for traffic, what programs are running, what other programs are installed, and what user accounts have been added.
Determine if there are decent backups. The exact nature of the backups may vary among different organizations, but some simple criteria that should be properly dealt with is to make sure that all critical information information is backed up, that backups are recent, and that backed up copies of the data do exist in sufficiently different geographic locations. If the backup is being transported bewteen locations via physical media, this can mean at least three copies: this allows for one at the business, one at a staff member's home, and one more (which might be getting transported between the business and the home).
Ask about backups early on. If sufficient backups are not occurring, see about getting the full resources to make some. If getting decent backups is being treated like a lower priority, then stress the importance of sufficient backups. Even if a business owner determines that backups are not important enough to be spending resources on, it may be worthwhile to be clear on the stance that getting sufficient backups should be a very high proirity of any organization which does not currently have them.
When helping somebody else, consider whether to obtain an agreement in writing before doing work on a system without backups. For example, the agreement may state that the IT staff has no liability on work done early in the process before sufficient backups are made, and that the costs of parts and labor to create reliable backups will be spent in a very short timeframe. Such an agreement is highly logical for a computer repair shop to obtain from a business before working on the business network. However, it may seem rather impersonal and business-like. Trying to protect one's self from such legal liability may be less valued when such an action would be more likely to strain a personal relationship. Whether this is wise to do with a family member, friend, or other acquantance may depend on various factors including how close one is to the family member, how trustworthy that person is, and so forth.
Some remaining topics:
Trust isolation: Plan to get a trusted system and to isolate distrust. Functionality isolation: Isolate functionality. For instance, perhaps automatic addressing or name resolution are initially handled by two specific services running on a single machine. This way if one implementation breaks or it is desirable to upgrade to a new implementation (perhaps to add features like redundancy, or perhaps because the new implementation is running on new hardware), the transition can be easier. For existing systems: Determine trust level. See how it is used. This could involve network monitoring. Create admin account. These may be usable for logging. Even if system will be replaced soon, see about changing existing passwords or disabling accounts. Even if the system will be getting replaced soon: If the functions of this system will be replaced within an hour, then it could be argued that disabling existing accounts may not be worthwhile. The counter-argument: Disabling accounts may be less likely to cause problems.
- Trust isolation
This section may need re-vamping. Plan to isolate distrust. Different software and systems may have different levels of trust. Attempting to eliminate distrust entirely can lead to limitations. , the best thing to do is to have the most trusted setup possible and ferociously isolate distrust. A useful network may have multiple services being provided: , such as files being available to machines that are directly being used by end users, or web browsers on end machines providing information to end users. The level of trust may vary between different services. Different services may have different amounts of trustworthiness.
Assuming the desired end result is going to be to have a trusted network, and to have the most critical, trusted systems to be extremely trustworthy. Before working too much on a system, start by assessing its trust level. The way to have a secure network is have trusted code, make sure that trusted code remains trusted, and then replace untrusted code with more trusted code.
There are advantages to trusted code: It is far less likely to unknowingly end up working maliciously. The keys, though, are to start with trusted code and to keep it trusted.
There are tempting reasons to allure people to run less trustworthy software code. It may be less expensive, have additional options, or seem easier to use. Also, the amount of trust given to a piece of software is something that may vary between different people and organizations, and may also change. It is expected that there will be interest by somebody to run code which may be less truthworthy.
The way to keep the most critical services trusted to the maximum extent possible is to isolate distrust. Have a plan for how to run various pieces of software. For example, if there is some software which is desirable but which is less trusted, determine how to isolate it from infecting a main file server. Accomplishing this may involve trapping the less trustworthy code into a tightly confined sandbox. Another approach may be to set up strong network barriers around the main file server. Both approaches may be used.Different people and organizations may have different criteria as far as how much flexibility there is to run various software, and there may even be variances in how to determine the level of trust given to one piece of code compared to another. Suffice it to say, chances are good that some people will want to run code that is less trusted by another person.
There may be some advantages to working with less trusted code. This doesn't mean code that is known to be malicious. This means running software, typically obtained via the Internet.
There are various ways to determine how trustworthy the code is likely to be. Positive indicators include widespread use and available source code.
- Dealing with distrust
If the machine is being used in an unauthorized way, determine whether to intervene (yet) or whether to take another approach. Intervening may include terminating certain network connections, making sure such network connections don't re-appear, and stopping programs from running. Although these steps may fix problems, they may also alert somebody performing the unauthorized activity, which is why the first step is to determine whether to intervene (yet). There may be some other approaches to take first. Those other approaches may provide information that will be valuable down the road. They may also take some time to implement, and that time may allow additional unauthorized activity to occur. Which course of action to take may be a judgement call with no clear answer that is universally the best. Note that if criminal activity is occurring, there may be separate guidelines to make sure that a crime scene is not being tampered with. That is discussed further (in the section about intrustions), but since that scenario complicates things, let's look at some options when specific courses of action are not being mandated by the law or its representatives.
A simple and fast approach may be to determine what network connections exist: this may indicate how a user is remotely accessing the machine and what network address is being used to access the machine. Another thing to check is what programs are running: these details (active network connections and running programs) may change and so there may be some value in getting those details quickly.
Another approach may be to get network traffic routed through a network monitor that watches, and perhaps logs, packets. If the network monitor is “transparent”, it may have no real detectable impact on the network. Although such a device may increase the time it takes for network traffic to be processed, the amount of the time increase may be negligibly minimal.
When intervening, try not to lose data. For example, if software is discovered to be attacking the network, don't immediately delete such software until figuring out if there is a more valuable process to take. If the software is running, try to find out relevant information (such as what username owns the process, what command line was used, and perhaps how long it has been running). To disable the software, consider whether to move the software to a safe location so that the software is no longer available in the location where it was. There may be some value in studying the software, and that may not be an option after it has been removed. However, when things have settled down and there doesn't appear to be any value in keeping the software, the commonly desired course of action may be to treat it like any other useless data.
- Determine how the machine is being used
Before logging in, see what information is available. For example, in a Microsoft Windows computer, the computer may show the name of the last logged-on user. That may be a convenient way to get useful information, such as what user typically uses the machine.
Determine who is using the machine, and where the machine is being used from. Look for valid network connections (
). Determine what users are currently using the machine (logged on). (Unix:
. Unix and Windows: Determine what processes are running and who owns the processes. Unix:
with various parameters that vary: perhaps
-auxwwwill be nice or perhaps the hyphen should be avoided or perhaps some of those parameters won't work. Windows: Command line options may include
. For a graphical approach, there is Task Manager. Click on the “Users” tab. Also, on the processes tab, look for a checkbox or a button that shows processes by all users.
Getting the name of the machine may be a clue as to its intended use. In Unix:
. If that file doesn't exist, perhaps check
and/or, instead of using
, specify the loopback addresses (127.0.0.1 to check for IPv4, and ::1 for IPv6)
Review system logs. Especially when it is quick and easy to do, check the operating system logs for errors and warnings.
Check for scheduled events:
- Checking scheduled events in Microsoft Windows
Windows: Check task scheduler. (Possibly
- Checking scheduled events in Unix
Unix: Check system-wide cron table, at, and user's cron tables. (System-wide cron tables may be seen with “
”, while user cron tables can be seen with “
” (e.g. “
See the list of installed programs. For Windows, this involves checking the Start menu of a logged in user, and checking the Control Panel's related “Programs” applet. (More thorough checking can be done by also checking
%ProgramFiles%(on supporting operting systems, or "
%windir%\..\Program Files"), %ProgramFiles(x86)% (if that is set, which will likely only be true on 64-bit operating systems, and may be "C:\Program Files (x86)"), and the
Unix: Check the package manager. To be even more thorough, investigate /usr/local/bin and the path.
Determine which accounts are administrator-level accounts. (Windows: For all machines (except perhaps the domain controller?) see the group called Administrators.
. If there is an active directory domain, but the "Domain Admins" group is not in the local Administrators group, consider whether that should change. Also if there is an active directory domain, check the "Domain Admins" group on the domain controller. (The "Domain Admins group is likely to in the Administrators group of machines in the domain.) Unix:
. (Different if using gshadow?)))
Check what accounts exist on the local machine. Many machines may have relatively few accounts which aren't accounts created by default. : Identify which accounts are likely custom accounts that were created on this machine. Determine how each account is used: This may involve techniques such as seeing what groups the account is in. Determine the purpose of all such accounts. Pay close attention to accounts which are administrators.
- Add a user
Each person who will be using the machine should be using a separate account. This allows for logs to be accurate and precise. Changes should be able to be easily made to one user's account without affecting the accounts used by other users. If two or more people use a computer at the same time (which may easily happen when less than two of those users are doing so remotely), the login being used can help identify who is actually logged in. In general, these are all good things. Although many organizations have operated without employing the practice of a separate account for each user, and so such a practice may not be immediately applied to all existing computers, do positively participate in the practice by making sure a specific account is made.
The first step should be to make sure there is a decent backup of the user database. If not, make one. Actually, it is preferred that all important data is backed up, which may involve backing up all the data on the computer or even the entire network. At minimum, though, make sure that important data (like a user database) is sufficiently backed up before changing that data.
Some of this may be able to be automated. For Microsoft Windows, tasks like installing a service pack might actually be able to be completed by modifying the installation procedure, using a process called slipstreaming, rather than waiting until after the OS is installed.
First, install the OS.
There may be hardening guides elsewhere. Often they cover some specific steps. It is advisable to review this guide to make sure that all the good general steps recommended by this guide are covered by any other guide that may be taken.
The Multi-VM guide currently has some information about Configuring a new system. Much, perhaps all, of that information may be moved to this page soon.Some hyperlinks: