If your laptop has a TPM, I'd highly recommend BitLocker. This way, you can allow people their non administrative user to do what they need to do in a guest account, but if they decide to try getting around the protection by booting an OS CD, they will be faced with an encrypted hard drive.
Of course, TrueCrypt is good as well, but the main advantage of BitLocker is that with a TPM, it requires no boot passphrase, and in a multi user environment, there is likely someone shoulder surfing in hopes to get it.
One other benefit of extended virtualization is that the host OS can offer some security measures that guests can't.
For example, if I am running Windows Server 2008 on hardware that supports it (TPM + VM extensions in the CPU), I can use BitLocker or TrueCrypt to encrypt the system disk and the disks that the VMs run on.
This way, if I'm using an app that is in a MS-DOS VM on a laptop, if the laptop is stolen, the data inside is protected, even though MS-DOS usually doesn't have that much in the start of the art disk encryption (perhaps an old version of Stacker that supports password protection, but that's basically it.)
If you have physical machines connected to the same SAN, both VMWare's products and Microsoft's Hyper-V support running failover clustering. This way, if one of the machines goes down, the VM and its services keep running with perhaps a small delay (in milliseconds) while the handoff to the other machine takes place.
The advantage of failover clustering at this level as opposed to the application level is that not all applications have the ability to use clustering, and a lot of companies may have database utilities that support clustering, but the app running on it may have issues, and making code for a handover at the app level might be impossible, especially if the utility is a niche item.
Another advantage of virtualization is the ability to do a hardware upgrade without affecting anything in the VM. For example, I have had a VM running on my Linux box that was a DHCP server and DNS cache. When it became time to move to a new machine because the 1999 vintage Linux box used too much power, I just copied the VM disk files to the new box, upgraded the client side OS drivers, and called it done. To stuff running in the VM, all it would notice is that it run faster, but everything else would be exactly the same. Similar with filesystem manipulation. If I want to move the VM to a new disk, I just turn it off, move the files to the new volume, turn it back on. The VM doesn't care one bit that its virtual disks are on a new SATA drive than an old IDE.
OS snapshotting comes to mind too. One of the uses I use a VM for is snapshots and rollbacks. For example, I tend to browse the Web in a VM under VirtualPC. This way, if some malicious code makes it past Firefox/Adblock/NoScript, it will only affect the VM (barring a hole that allows code to affect the hypervisor executable), and a simple click on the close window button dumps all changes. Another use is system upgrades. Say I do a major upgrade or patch of an application and the app won't start. I can rollback to a previous snapshot, turn the VM on, and be able to resume production with that machine without running out of time in the service window.
Filesystem manipulation. If you have the software, backing up VMs becomes easy. You have either a tape drive, a disk to hold stuff on, or both. The VM can be happily running, and at the same time, its filesystem can be snapshotted outside the OS and backed up.
There is a penalty for using a VM, and that is performance. However, this is mitigated significantly by having drivers in the client OS. For example, Hyper-V has a very fast virtual network switch, and it supports a virtual 100baseT adapter. So, just by installing the client drivers, a VM can communicate with others on the same virtual switch a lot faster than without.
Another penalty is unknown security issues. There is always the concern that a hypervisor can be compromised, and malicious code that is running in a VM can get the machine access of the hypervisor (whose drivers for a lot of tasks might be running with root or kernel level authority). This can be mitigated by making sure the guest operating systems are secure.
I know Cisco has the NAC Appliance (formerly CleanAccess) which does exactly this. This functionality can be coupled with Windows Server 2008 domains to point infected machines to a remediation server to get cleaned up and some decent A/V software installed.
In a business, the NAC (network admission control) functionality can also be used to enforce having various programs present on a machine, such as PGP Universal, Symantec Endpoint Protection, and others.
3: The people doing the computer compromising will just compromise the IUL, and use the license granted to Aunt Tillie so she can use Windows XP. The black hats then get free reign under a legal ID, and someone else takes the blame, perhaps a prison term.
I like the idea of having a civilian version of a CAC so one can use their client certificate (stored on a tamper resistant cryptographic token or a cellphone) instead of usernames/passwords that are intercepted by keylogging software. More points if there is a way to enter one's PIN on a device not connected to the computer, so a compromised computer can't obtain anything pertinent about someone's client key or unlocking PIN.
Best of all worlds would be a device similar to what IBM prototyped that would communicate with the bank via SSL so one can see what he or she is transferring and approve/disapprove so there is protection against active man in the middle attacks.
However, I don't like the idea of forcing people to have some type of number or identity to use the Internet. Its just too juicy a target for compromise, and would not do much in stopping the problem.
Since the property has an OEM sticker, in theory, the thief can use VLK media without IP infringement and complying with the EULA. Physical theft charges are another story, of course.
Actually, if someone did a show-stopper like that it would be a bad thing for everyone. It would provide the impetus for the Internet to be split up into separate non-connected networks and walled gardens. These wouldn't be "mere" firewalls, these would be networks that would be either running a new (or old) network protocol (IPX is an example) or a non routable protocol such as NetBEUI (Don't confuse NetBEUI with NetBIOS... NetBEUI is the transportation and is obsolete, as TCP/IP has completely taken over that communication layer function over) or Appletalk.
Right now, a black hat can sit at his/her computer, and connect on the same network to virtually anything. Should people get too upset and knee-jerkish about a War Games scenario, he or she would have to spend a lot of time and effort trying to get gateways working to networks that have completely different protocols (IPX, VINES) in the effort to try to attack machines.
Compared to the past, a dedicated cracker just needs to focus on a relative small part of an OS or a service like Apache, IIS, or SQL Server for great gains. In the past, one had to jump from DECNet to BITNET to NSFNet, perhaps doing through multiple UUCP hops if the boxes were moving mail via store and forward and mdoems. Almost no host or network was the same as another, so a generic "script kiddy" who could run a prepackaged toolkit against a random company didn't exist back then.
Classified+ information isn't available off a webserver on the Internet. If it is, someone would be being headed to the military prison at Leavenworth for a very long time.
I have been to work environments where people documented things... but one's person view of the network in his documentation is totally different than what someone else had, especially with regards to which switch went to what vlan. Documentation gets useless when four people have five world-views on what is going on, especially what is connected to what punchdown block.
The trick is to have centralized documentation on a server, but make sure the machine is both locked down six days from Sunday, and religiously backed up. Not just hang an external drive from it, but if possible, archive everything to DVD and keep multiple DVD copies offsite. If a wiki is used, back up the mySQL database, copy that file to the DVD, as well as the wiki's config directory. In a UNIX shop, I would consider a wiki, have Apache run SSL only, and require a username/password for any type of access.
Of course, document how the central documentation server is laid out, and have this documentation be in a standard format that your organization uses. Of course, have a hardcopy filed away in a physical filing cabinet just in case machines are down. The passwords for the central documentation server would be written down, inserted in a sealed envelope, and put in a place that only the CxOs and other corporate officers of the company have access.
Of course, one thing I stress about servers such as backup servers and documentation servers is to not just have network security, but to have some physical protection. Most UNIX variants are starting to have hard disk encryption. On the Windows side, I'd highly recommend a machine with a TPM and BitLocker. Other utilities like PGP or TrueCrypt is also good for this. The advantage of BitLocker is that you can set a PIN on the TPM, and the TPM limits brute force guessing. Of course, if the machine needs recovered, just stick in a usb flash drive right out of the tape safe, and it will boot just in case the PIN got forgotten. On this server, you want both security and recoverability.
As for things to document, network topology, machines, and perhaps a database storing machine passwords if the machine is secure enough. There are two other things:
First, document recovery mechanisms for machines. TrueCrypt's system encryption will have a user make a recovery CD (it can be turned off, but on by default.) PGP can offer recovery keys or passphrases. BitLocker will have a recovery key consisting of a 48 digit password. Windows EFS can have a data recovery agent key generated and the private part stored offline. Store all of these, especially of core machines in a secure, but retrievable place. This way, you can get access to a user's machine or a server if it was rendered unbootable, or the TPM on it was reset.
Second, document invoices, perhaps store them in a standard format your company uses, be it TIFF files, PDFs, or other.
The reason that documenting invoices is important are audits by the SIAA and BSA. There are a lot of people who, if fired for any reason, will immediately turn around and file a report with the copyright enforcement big guns alleging copyright infringement at the company. Soon after, you will have some attorneys requesting both a list of what software is licensed to what machines, and copies of invoices. Turn them away, they will be back with the constable, a motion of discovery, and a demand for the information they were requesting several hours ago. If you have the two, and the invoices show everything is licensed, you are free and clear, and likely won't be bothered by the guys again. If your records stink with no proof that anything was bought (and no, CD keys and "proof of licenses" jammed in some file drawer don't count), things start to go real painful real fast. So, having the ability to run an audit, print a list of machines and what they are running (OS and apps), then print the pertinate invoices showing that the machines are properly licensed is crucial for a business.
Finally, it doesn't hurt to have your own personal documentation trail on a secure part of your main workstation. This can help if a blamestorming fest occurs because a cow-orker toasted the Web server and starts pointing fingers at the other admins.
I agree on the PSU. The PSU is the foundation of the computer, and if something goes wrong with it, it can completely fry every other component on the system. I'd get an Antec, PC Power & Cooling, or Corsair PSU, with a large amount of wattage. 300 watt PSUs doesn't mean components are getting the current they need on all rails when the PSU is near capacity, so its always good to leave a lot of headroom, especially because people don't factor in that external USB stuff needs power. IMHO, $50 is the lowest I'd go for a power supply, and if its a machine that will have a bunch of drives, I'd go with 800 to 1000 watts just in case.
Another advantage is that quality power supplies are silent, which makes using a machine a lot more pleasurable.
I'd like to see a "BIOS OS" whose job it is to function as a recovery mechanism. Optionally, it would have support for the most populat whole disk encryption products (Bitlocker, Truecrypt, PGP, and others), so if the MBR of a drive got scrozzled, one can still be able to access the data without trying to hunt down (or make) a specific recovery CD. This would also allow offline antivirus checking should the encrypted OS get infected.
Of course, add the standard recovery tools, from chkdsk to tools for backups and restores to either another hard disk, a remote server, or a CD or DVD.
The problem is that Java had security issues, but they were not ones that were focused on by malware writers until recently. There were other exploits that were easier to find and use to add more members to a botnet. However, this has changed with Vista and Windows 7. Vista has a lot of under the hood security features (ASLR is just one), and because the attack surface of an average Windows machine is getting smaller, the black hats are moving outwards from the OS to Web based plugins which can get their software running at least with user access, perhaps as Administrator or LocalSystem if someone has XP, or has UAC disabled.
Essentially what JVMs need is a second layer of protection, where anything that escapes doesn't get the access of the user its running under. This means (to use a random analogy) not just line the sandbox with thick metal plating so stuff doesn't escape, but have a camera watching watch what things are doing in the sandbox to catch exploits proactively. The best way to do this is to take a hypervisor like approach to JVMs. This means isolating the process that does the Java machine in a low privilege mode if on Windows like how IE is done on Vista and newer, or an OS created jail on BSD variants, so if the worst does happen and a process does escape the sandbox, the damage can do will be very limited. However, the more isolation, the less performance, and Java got a bad rep for poor performance initially, although this was mitigated by JIT environments and other improvements.
Of course, this won't help things if a signed java application (as opposed to an applet) is malicious, but installing a Java application that is intended not to be in a sandbox falls under the umbrella of watching where one gets executables from, and making sure signatures (either the Java signed files, or PGP/gpg sigs) are valid.
Re:...only if the BIOS chip is replaceable.
on
Phoenix BIOSOS?
·
· Score: 1
Elaborating on this concept, why not three?
The first bank has a "1.0" flash. This is what ships on the motherboard originally, and is put into an unwritable ROM. (Yes, this sounds redundant, but I'm meaning burned on chip and completely unwritable outside of a chip fab as opposed to an EEPROM.)
The second and third banks are ready to go for whatever updates.
This way, should some malware erase the primary flash BIOS and the secondary, the machine is still usable by pointing it somehow to the original "1.0" ROM, then when the user can fix it, re-flash the BIOS with an updated version.
This is a lesson every system administrator worth his or her salt learns over the long haul. You might back up dutifully, test restore, and have a well done system of ensuring backups are rotated correctly. Then you find out the tape drive you use is miscalibrated so only it can read your backup tapes, or you find the backup software you use on a daily basis is not in production, or the latest version has no support for the backlevel formats.
I have found that in a production environment, you really need multiple methods for backup if at all possible:
The first level is a dedicated backup server. This machine is locked down to the best of your abilities, and firewalled from the network, only allowing critical ports such as what the backup software uses, and perhaps ssh or RDP (if a Windows box). This machine copies everything from the other servers onto a large disk array, then to tape. The tapes are then cycled offsite via a service like Iron Mountain. Of course, the tapes are encrypted, and corporate officers get a copy of the master keys.
Why tapes? Because they can be set read only after they are dismounted, and no computer, no matter how infected can modify or delete the tape contents once this is done, outside of a reflash of the tape drive's BIOS. This is important because its not unheard of for someone to write a program that trashes backups over a time interval. Higher end tapes can be used as WORM media like DLT-ICE.
I can't emphasize enough about securing the backup server, both physically and network-wise. If this box gets compromised, all your data is available. On Windows machines, I recommend using some form of disk encryption (Bitlocker if the machine has a TPM, TrueCrypt, etc) so if the backup server or an array gets physically stolen, the data is of no use to a thief. This is in addition to the backup program's encryption.
After you have a central backup server installed, secured (security is paramount on this machine unless the backup program client can do encryption), and backups running, you focus on the other levels of backup.
The next level of backup is on the local servers. Most operating systems have a method of backing up the computer. If you can do this with a server, fire off a snapshot backup every month or so. Most OS backup methods don't have encryption, so this backup should go directly to a tape safe or secured container in the data center. Optionally, you can install backup software locally that can encrypt. I like using the backup/restore utility the OS gives for an image every quarter, then using more secure software more often, so the OS backups can be stored in a tape safe or physically secure container. This way, if the third party backup software ends up inoperable, there is still a method of getting a machine up somehow, or putting it in a virtual machine for recovery purposes.
Finally, after you have backup servers and a rotation, companies might consider offsite cloud backup services like Mozy. Mozy offers use of keyfiles so all data is stored encrypted (encrypted on the client end). Of course, making sure the encryption key is stored safely is paramount, and the cost of storing a large backup in Mozy's cloud may be prohibitive. However, if worse comes to worst and your site is completely knocked out, as well as the offsite backup site, it may be thing that keeps your business up.
Of course, scale this up or down as per your company's needs. A smaller business can get by using Mozy and a Windows Server 2008 box running Bitlocker, a network backup program with encryption such as Retrospect or Backup Exec, and using external drives every month to copy backup sets from the main ones to store offsite.
A larger business might see about a true backup fabric system sold by IBM (TSM), EMC (Networker), or Microsoft's solution.
The key is to not just have some built in redundancy so if one backup method is not usable, you have another, even if the backups are older, but to be able to do this in a manner that doesn't add too much time and equipment expense.
Re:It's called DOS, and it was done a long time ag
on
Phoenix BIOSOS?
·
· Score: 1
I remember some SCSI drives having exactly this functionality. Ages ago, I had/,/usr,/usr/bin,/lib, and the other nonchanging critical filesystems on a switchable read-only drive, while the rest were read-write. I also stored a MD5 hash of the stuff on the read-write side on the read-only filesystem, so I could check for changes in file contents. This, plus a couple good finds to find bad permissions made for extremely solid security.
Same with a FTP server I had with critical files on it. The files were stored on a read-only drive, and even if the box got hacked, someone couldn't tamper with the files, although these days, someone would just modify the ftpd to change the files in transit to tampered versions.
Re:A button for switching main boot hard disk...
on
Phoenix BIOSOS?
·
· Score: 1
I'd like to see a TPM and BitLocker like functionality handled in the hypervisor, where the operating systems don't care or don't see any hard disk encryption, but if someone jacks a hard drive, the contents would be useless. Add a PIN to the TPM, and this would be excellent security for a laptop.
This functionality would be great for servers too, so if someone steals the database server running RedHat, the contents would be protected, without requiring someone physically onsite to enter a passphrase, or additional infrastructure to allow for hardware remote consoles.
Its a tool, and can be used for good/ill. I actively build/buy servers and laptops with TPM functionality because it allows me to enable encryption with BitLocker, save the recovery key someplace secure (safe deposit box), and from there on out, the encryption is completely forgotten about. On laptops, I enable the PIN functionality so an intruder would have to have the tech of a chip fab to coax the information needed to grab the HD contents. Even though TPM chips are not hardened against physical attack, few thieves outside of intel agencies have the tech to rip open a chip's package and attach probes to the chip's microscopic pads.
Either way, servers can reboot unattended while the data is encrypted, and laptops are protected against brute force password attacks. If an intruder tries to repeatedly guess a PIN, the TPM will just keep forcing longer and longer delays, if not permanently locking.
All a TPM is, is a cryptographic token that is on the hardware, with two pieces of additional functionality: The ability to validate that the MBR and booting parts of the hard disk have not been tampered with, and remote attestation.
The ability to check for tampering is important because in theory, someone can put a keylogger on the boot sector, then pass the info onto the real preboot authentication system (PGP or TrueCrypt) while saving the boot passphrase for an attacker in some safe area. If someone tries to tamper with the BitLocker subsystem, the TPM won't allow the machine to boot and it will be obvious that something is fishy.
Remote attestation is controversial, but you don't have to turn it on in BIOS. Same with Intel's vPro stuff.
Finally, by the TPM spec, all TPM chips are shipped turned off and disabled by default, so a software maker can't depend on one for DRM reasons.
A fourth would be separation of data onto different databases on different servers. If social security numbers are not needed, have those stored in a smaller armored database that doesn't connect to the Web. Instead, use another number.
This way, if an application needs information, it can grab what it needs, but no more.
Depends who has the IP rights. The IP could vanish forever into thin air like a lot of the Origin IP after it got bought out by EA. I'm hoping that someone who owns the rights can put out not just DNF, but sequels to it, because Duke Nukem is a very distinct game character, and a nice fun change from the usual 3D shooters out there.
It would add significant cost, but perhaps a small e-paper display could have been put on the bottom or covered by a lid that would have a password, and another button on the unit to change the PW instantly. This way, one could be using their wireless connection at one location, then at some other place, push the button, configure their laptop to switch as well.
Another idea would be adding a rudimintary RADIUS server onto the card and just use the enterprise-level authentication, and not worry about WPA passwords. However, some type of password would be needed to initially configure or reset the device, so this may not be the best of ideas.
Realistically, this is a very low risk to most people. However, session hijacking and packet sniffing via TCP was considered a low risk as well in the past.
One reason I go for BT mice over generic USB radio is the fact that BT traffic is encrypted once the devices are paired. Someone sniffing traffic would not be able to figure out your mouse patterns, or even worse take control of your mouse and start clicking on stuff.
Similar with a BT keyboard versus a wireless keyboard and either intercepting keystrokes or injecting them.
I wasn't sure from the TFA, but previous holo disks were WORM media, where they were intended for archiving.
With media this inexpensive, it would be a boon for both hospitals, but companies in general who have to archive everything, due to Sarbanes Oxley, HIPAA, CALEA, and other regulations.
What GE will need to work on, once this comes out in a standard cartridge format, is some type of autochanger that can reliably move media in and out. In days of yore where companies had WORM optical media, one loaded a library with 50-100 disks, and as they got full, labeled them, swapped them out for empty ones, and either stored them in a tape safe, or dropped them in a tub for Iron Mountain to pick up and store.
That is a pretty sweeping statement, similar to saying that all American companies can't lock their doors down.
This varies by department, organization, and sysadmin. A lot of US government divisions have intelligent, alert, and aware employees who do a good job at what they do. However, these people don't make the news.
This is one of the things with IT. If you do a good job, nobody notices. Its only if stuff fails is when people notice. Same thing with this mess.
This same thing can be said about hardware. If your hardware was compromised at the IC level, (say a certain string of gibberish would allow ring zero access) then no OS security would matter, and the only way to even slow this down would be a special hypervisor that intercepted every single assembly instruction... and even in this case, there would be ways to probably hide stuff with various variable and register states.
How about not cyber soldiers, but true IT professionals who know their field?
Security is not all about the technological side. A major part of security is dealing with social engineering. Another major part is dealing security needs of a department or organization. Security and infrastructure needs of a law firm with 5 workstations and a server are totally different from the security of a multi-location corporate environment. Security needs of a TS facility are absolutely different from an unclassified facility.
The "whiz kids" are an important part of this, but you also need security people who can handle not just finding the more exotic bugs, but be able to make sure that a department, enterprise, or organization are up to speed. You need people who can (for example) LART the reprobate who is in receiving and who is browsing pr0n on a workstation with the AV program disabled and IE's security set to "low" so he doesn't get asked to install IE controls that stand between him and his excitement.
Security takes a lot of puzzle pieces, and people with many talents.
Slashdot Mirror
If your laptop has a TPM, I'd highly recommend BitLocker. This way, you can allow people their non administrative user to do what they need to do in a guest account, but if they decide to try getting around the protection by booting an OS CD, they will be faced with an encrypted hard drive.
Of course, TrueCrypt is good as well, but the main advantage of BitLocker is that with a TPM, it requires no boot passphrase, and in a multi user environment, there is likely someone shoulder surfing in hopes to get it.
One other benefit of extended virtualization is that the host OS can offer some security measures that guests can't.
For example, if I am running Windows Server 2008 on hardware that supports it (TPM + VM extensions in the CPU), I can use BitLocker or TrueCrypt to encrypt the system disk and the disks that the VMs run on.
This way, if I'm using an app that is in a MS-DOS VM on a laptop, if the laptop is stolen, the data inside is protected, even though MS-DOS usually doesn't have that much in the start of the art disk encryption (perhaps an old version of Stacker that supports password protection, but that's basically it.)
Virtualization isn't just about performance:
If you have physical machines connected to the same SAN, both VMWare's products and Microsoft's Hyper-V support running failover clustering. This way, if one of the machines goes down, the VM and its services keep running with perhaps a small delay (in milliseconds) while the handoff to the other machine takes place.
The advantage of failover clustering at this level as opposed to the application level is that not all applications have the ability to use clustering, and a lot of companies may have database utilities that support clustering, but the app running on it may have issues, and making code for a handover at the app level might be impossible, especially if the utility is a niche item.
Another advantage of virtualization is the ability to do a hardware upgrade without affecting anything in the VM. For example, I have had a VM running on my Linux box that was a DHCP server and DNS cache. When it became time to move to a new machine because the 1999 vintage Linux box used too much power, I just copied the VM disk files to the new box, upgraded the client side OS drivers, and called it done. To stuff running in the VM, all it would notice is that it run faster, but everything else would be exactly the same. Similar with filesystem manipulation. If I want to move the VM to a new disk, I just turn it off, move the files to the new volume, turn it back on. The VM doesn't care one bit that its virtual disks are on a new SATA drive than an old IDE.
OS snapshotting comes to mind too. One of the uses I use a VM for is snapshots and rollbacks. For example, I tend to browse the Web in a VM under VirtualPC. This way, if some malicious code makes it past Firefox/Adblock/NoScript, it will only affect the VM (barring a hole that allows code to affect the hypervisor executable), and a simple click on the close window button dumps all changes. Another use is system upgrades. Say I do a major upgrade or patch of an application and the app won't start. I can rollback to a previous snapshot, turn the VM on, and be able to resume production with that machine without running out of time in the service window.
Filesystem manipulation. If you have the software, backing up VMs becomes easy. You have either a tape drive, a disk to hold stuff on, or both. The VM can be happily running, and at the same time, its filesystem can be snapshotted outside the OS and backed up.
There is a penalty for using a VM, and that is performance. However, this is mitigated significantly by having drivers in the client OS. For example, Hyper-V has a very fast virtual network switch, and it supports a virtual 100baseT adapter. So, just by installing the client drivers, a VM can communicate with others on the same virtual switch a lot faster than without.
Another penalty is unknown security issues. There is always the concern that a hypervisor can be compromised, and malicious code that is running in a VM can get the machine access of the hypervisor (whose drivers for a lot of tasks might be running with root or kernel level authority). This can be mitigated by making sure the guest operating systems are secure.
I know Cisco has the NAC Appliance (formerly CleanAccess) which does exactly this. This functionality can be coupled with Windows Server 2008 domains to point infected machines to a remediation server to get cleaned up and some decent A/V software installed.
In a business, the NAC (network admission control) functionality can also be used to enforce having various programs present on a machine, such as PGP Universal, Symantec Endpoint Protection, and others.
3: The people doing the computer compromising will just compromise the IUL, and use the license granted to Aunt Tillie so she can use Windows XP. The black hats then get free reign under a legal ID, and someone else takes the blame, perhaps a prison term.
I like the idea of having a civilian version of a CAC so one can use their client certificate (stored on a tamper resistant cryptographic token or a cellphone) instead of usernames/passwords that are intercepted by keylogging software. More points if there is a way to enter one's PIN on a device not connected to the computer, so a compromised computer can't obtain anything pertinent about someone's client key or unlocking PIN.
Best of all worlds would be a device similar to what IBM prototyped that would communicate with the bank via SSL so one can see what he or she is transferring and approve/disapprove so there is protection against active man in the middle attacks.
However, I don't like the idea of forcing people to have some type of number or identity to use the Internet. Its just too juicy a target for compromise, and would not do much in stopping the problem.
Since the property has an OEM sticker, in theory, the thief can use VLK media without IP infringement and complying with the EULA. Physical theft charges are another story, of course.
Actually, if someone did a show-stopper like that it would be a bad thing for everyone. It would provide the impetus for the Internet to be split up into separate non-connected networks and walled gardens. These wouldn't be "mere" firewalls, these would be networks that would be either running a new (or old) network protocol (IPX is an example) or a non routable protocol such as NetBEUI (Don't confuse NetBEUI with NetBIOS... NetBEUI is the transportation and is obsolete, as TCP/IP has completely taken over that communication layer function over) or Appletalk.
Right now, a black hat can sit at his/her computer, and connect on the same network to virtually anything. Should people get too upset and knee-jerkish about a War Games scenario, he or she would have to spend a lot of time and effort trying to get gateways working to networks that have completely different protocols (IPX, VINES) in the effort to try to attack machines.
Compared to the past, a dedicated cracker just needs to focus on a relative small part of an OS or a service like Apache, IIS, or SQL Server for great gains. In the past, one had to jump from DECNet to BITNET to NSFNet, perhaps doing through multiple UUCP hops if the boxes were moving mail via store and forward and mdoems. Almost no host or network was the same as another, so a generic "script kiddy" who could run a prepackaged toolkit against a random company didn't exist back then.
Classified+ information isn't available off a webserver on the Internet. If it is, someone would be being headed to the military prison at Leavenworth for a very long time.
I have been to work environments where people documented things... but one's person view of the network in his documentation is totally different than what someone else had, especially with regards to which switch went to what vlan. Documentation gets useless when four people have five world-views on what is going on, especially what is connected to what punchdown block.
The trick is to have centralized documentation on a server, but make sure the machine is both locked down six days from Sunday, and religiously backed up. Not just hang an external drive from it, but if possible, archive everything to DVD and keep multiple DVD copies offsite. If a wiki is used, back up the mySQL database, copy that file to the DVD, as well as the wiki's config directory. In a UNIX shop, I would consider a wiki, have Apache run SSL only, and require a username/password for any type of access.
Of course, document how the central documentation server is laid out, and have this documentation be in a standard format that your organization uses. Of course, have a hardcopy filed away in a physical filing cabinet just in case machines are down. The passwords for the central documentation server would be written down, inserted in a sealed envelope, and put in a place that only the CxOs and other corporate officers of the company have access.
Of course, one thing I stress about servers such as backup servers and documentation servers is to not just have network security, but to have some physical protection. Most UNIX variants are starting to have hard disk encryption. On the Windows side, I'd highly recommend a machine with a TPM and BitLocker. Other utilities like PGP or TrueCrypt is also good for this. The advantage of BitLocker is that you can set a PIN on the TPM, and the TPM limits brute force guessing. Of course, if the machine needs recovered, just stick in a usb flash drive right out of the tape safe, and it will boot just in case the PIN got forgotten. On this server, you want both security and recoverability.
As for things to document, network topology, machines, and perhaps a database storing machine passwords if the machine is secure enough. There are two other things:
First, document recovery mechanisms for machines. TrueCrypt's system encryption will have a user make a recovery CD (it can be turned off, but on by default.) PGP can offer recovery keys or passphrases. BitLocker will have a recovery key consisting of a 48 digit password. Windows EFS can have a data recovery agent key generated and the private part stored offline. Store all of these, especially of core machines in a secure, but retrievable place. This way, you can get access to a user's machine or a server if it was rendered unbootable, or the TPM on it was reset.
Second, document invoices, perhaps store them in a standard format your company uses, be it TIFF files, PDFs, or other.
The reason that documenting invoices is important are audits by the SIAA and BSA. There are a lot of people who, if fired for any reason, will immediately turn around and file a report with the copyright enforcement big guns alleging copyright infringement at the company. Soon after, you will have some attorneys requesting both a list of what software is licensed to what machines, and copies of invoices. Turn them away, they will be back with the constable, a motion of discovery, and a demand for the information they were requesting several hours ago. If you have the two, and the invoices show everything is licensed, you are free and clear, and likely won't be bothered by the guys again. If your records stink with no proof that anything was bought (and no, CD keys and "proof of licenses" jammed in some file drawer don't count), things start to go real painful real fast. So, having the ability to run an audit, print a list of machines and what they are running (OS and apps), then print the pertinate invoices showing that the machines are properly licensed is crucial for a business.
Finally, it doesn't hurt to have your own personal documentation trail on a secure part of your main workstation. This can help if a blamestorming fest occurs because a cow-orker toasted the Web server and starts pointing fingers at the other admins.
I agree on the PSU. The PSU is the foundation of the computer, and if something goes wrong with it, it can completely fry every other component on the system. I'd get an Antec, PC Power & Cooling, or Corsair PSU, with a large amount of wattage. 300 watt PSUs doesn't mean components are getting the current they need on all rails when the PSU is near capacity, so its always good to leave a lot of headroom, especially because people don't factor in that external USB stuff needs power. IMHO, $50 is the lowest I'd go for a power supply, and if its a machine that will have a bunch of drives, I'd go with 800 to 1000 watts just in case.
Another advantage is that quality power supplies are silent, which makes using a machine a lot more pleasurable.
I'd like to see a "BIOS OS" whose job it is to function as a recovery mechanism. Optionally, it would have support for the most populat whole disk encryption products (Bitlocker, Truecrypt, PGP, and others), so if the MBR of a drive got scrozzled, one can still be able to access the data without trying to hunt down (or make) a specific recovery CD. This would also allow offline antivirus checking should the encrypted OS get infected.
Of course, add the standard recovery tools, from chkdsk to tools for backups and restores to either another hard disk, a remote server, or a CD or DVD.
The problem is that Java had security issues, but they were not ones that were focused on by malware writers until recently. There were other exploits that were easier to find and use to add more members to a botnet. However, this has changed with Vista and Windows 7. Vista has a lot of under the hood security features (ASLR is just one), and because the attack surface of an average Windows machine is getting smaller, the black hats are moving outwards from the OS to Web based plugins which can get their software running at least with user access, perhaps as Administrator or LocalSystem if someone has XP, or has UAC disabled.
Essentially what JVMs need is a second layer of protection, where anything that escapes doesn't get the access of the user its running under. This means (to use a random analogy) not just line the sandbox with thick metal plating so stuff doesn't escape, but have a camera watching watch what things are doing in the sandbox to catch exploits proactively. The best way to do this is to take a hypervisor like approach to JVMs. This means isolating the process that does the Java machine in a low privilege mode if on Windows like how IE is done on Vista and newer, or an OS created jail on BSD variants, so if the worst does happen and a process does escape the sandbox, the damage can do will be very limited. However, the more isolation, the less performance, and Java got a bad rep for poor performance initially, although this was mitigated by JIT environments and other improvements.
Of course, this won't help things if a signed java application (as opposed to an applet) is malicious, but installing a Java application that is intended not to be in a sandbox falls under the umbrella of watching where one gets executables from, and making sure signatures (either the Java signed files, or PGP/gpg sigs) are valid.
Elaborating on this concept, why not three?
The first bank has a "1.0" flash. This is what ships on the motherboard originally, and is put into an unwritable ROM. (Yes, this sounds redundant, but I'm meaning burned on chip and completely unwritable outside of a chip fab as opposed to an EEPROM.)
The second and third banks are ready to go for whatever updates.
This way, should some malware erase the primary flash BIOS and the secondary, the machine is still usable by pointing it somehow to the original "1.0" ROM, then when the user can fix it, re-flash the BIOS with an updated version.
This is a lesson every system administrator worth his or her salt learns over the long haul. You might back up dutifully, test restore, and have a well done system of ensuring backups are rotated correctly. Then you find out the tape drive you use is miscalibrated so only it can read your backup tapes, or you find the backup software you use on a daily basis is not in production, or the latest version has no support for the backlevel formats.
I have found that in a production environment, you really need multiple methods for backup if at all possible:
The first level is a dedicated backup server. This machine is locked down to the best of your abilities, and firewalled from the network, only allowing critical ports such as what the backup software uses, and perhaps ssh or RDP (if a Windows box). This machine copies everything from the other servers onto a large disk array, then to tape. The tapes are then cycled offsite via a service like Iron Mountain. Of course, the tapes are encrypted, and corporate officers get a copy of the master keys.
Why tapes? Because they can be set read only after they are dismounted, and no computer, no matter how infected can modify or delete the tape contents once this is done, outside of a reflash of the tape drive's BIOS. This is important because its not unheard of for someone to write a program that trashes backups over a time interval. Higher end tapes can be used as WORM media like DLT-ICE.
I can't emphasize enough about securing the backup server, both physically and network-wise. If this box gets compromised, all your data is available. On Windows machines, I recommend using some form of disk encryption (Bitlocker if the machine has a TPM, TrueCrypt, etc) so if the backup server or an array gets physically stolen, the data is of no use to a thief. This is in addition to the backup program's encryption.
After you have a central backup server installed, secured (security is paramount on this machine unless the backup program client can do encryption), and backups running, you focus on the other levels of backup.
The next level of backup is on the local servers. Most operating systems have a method of backing up the computer. If you can do this with a server, fire off a snapshot backup every month or so. Most OS backup methods don't have encryption, so this backup should go directly to a tape safe or secured container in the data center. Optionally, you can install backup software locally that can encrypt. I like using the backup/restore utility the OS gives for an image every quarter, then using more secure software more often, so the OS backups can be stored in a tape safe or physically secure container. This way, if the third party backup software ends up inoperable, there is still a method of getting a machine up somehow, or putting it in a virtual machine for recovery purposes.
Finally, after you have backup servers and a rotation, companies might consider offsite cloud backup services like Mozy. Mozy offers use of keyfiles so all data is stored encrypted (encrypted on the client end). Of course, making sure the encryption key is stored safely is paramount, and the cost of storing a large backup in Mozy's cloud may be prohibitive. However, if worse comes to worst and your site is completely knocked out, as well as the offsite backup site, it may be thing that keeps your business up.
Of course, scale this up or down as per your company's needs. A smaller business can get by using Mozy and a Windows Server 2008 box running Bitlocker, a network backup program with encryption such as Retrospect or Backup Exec, and using external drives every month to copy backup sets from the main ones to store offsite.
A larger business might see about a true backup fabric system sold by IBM (TSM), EMC (Networker), or Microsoft's solution.
The key is to not just have some built in redundancy so if one backup method is not usable, you have another, even if the backups are older, but to be able to do this in a manner that doesn't add too much time and equipment expense.
I remember some SCSI drives having exactly this functionality. Ages ago, I had /, /usr, /usr/bin, /lib, and the other nonchanging critical filesystems on a switchable read-only drive, while the rest were read-write. I also stored a MD5 hash of the stuff on the read-write side on the read-only filesystem, so I could check for changes in file contents. This, plus a couple good finds to find bad permissions made for extremely solid security.
Same with a FTP server I had with critical files on it. The files were stored on a read-only drive, and even if the box got hacked, someone couldn't tamper with the files, although these days, someone would just modify the ftpd to change the files in transit to tampered versions.
I'd like to see a TPM and BitLocker like functionality handled in the hypervisor, where the operating systems don't care or don't see any hard disk encryption, but if someone jacks a hard drive, the contents would be useless. Add a PIN to the TPM, and this would be excellent security for a laptop.
This functionality would be great for servers too, so if someone steals the database server running RedHat, the contents would be protected, without requiring someone physically onsite to enter a passphrase, or additional infrastructure to allow for hardware remote consoles.
Its a tool, and can be used for good/ill. I actively build/buy servers and laptops with TPM functionality because it allows me to enable encryption with BitLocker, save the recovery key someplace secure (safe deposit box), and from there on out, the encryption is completely forgotten about. On laptops, I enable the PIN functionality so an intruder would have to have the tech of a chip fab to coax the information needed to grab the HD contents. Even though TPM chips are not hardened against physical attack, few thieves outside of intel agencies have the tech to rip open a chip's package and attach probes to the chip's microscopic pads.
Either way, servers can reboot unattended while the data is encrypted, and laptops are protected against brute force password attacks. If an intruder tries to repeatedly guess a PIN, the TPM will just keep forcing longer and longer delays, if not permanently locking.
All a TPM is, is a cryptographic token that is on the hardware, with two pieces of additional functionality: The ability to validate that the MBR and booting parts of the hard disk have not been tampered with, and remote attestation.
The ability to check for tampering is important because in theory, someone can put a keylogger on the boot sector, then pass the info onto the real preboot authentication system (PGP or TrueCrypt) while saving the boot passphrase for an attacker in some safe area. If someone tries to tamper with the BitLocker subsystem, the TPM won't allow the machine to boot and it will be obvious that something is fishy.
Remote attestation is controversial, but you don't have to turn it on in BIOS. Same with Intel's vPro stuff.
Finally, by the TPM spec, all TPM chips are shipped turned off and disabled by default, so a software maker can't depend on one for DRM reasons.
A fourth would be separation of data onto different databases on different servers. If social security numbers are not needed, have those stored in a smaller armored database that doesn't connect to the Web. Instead, use another number.
This way, if an application needs information, it can grab what it needs, but no more.
Depends who has the IP rights. The IP could vanish forever into thin air like a lot of the Origin IP after it got bought out by EA. I'm hoping that someone who owns the rights can put out not just DNF, but sequels to it, because Duke Nukem is a very distinct game character, and a nice fun change from the usual 3D shooters out there.
It would add significant cost, but perhaps a small e-paper display could have been put on the bottom or covered by a lid that would have a password, and another button on the unit to change the PW instantly. This way, one could be using their wireless connection at one location, then at some other place, push the button, configure their laptop to switch as well.
Another idea would be adding a rudimintary RADIUS server onto the card and just use the enterprise-level authentication, and not worry about WPA passwords. However, some type of password would be needed to initially configure or reset the device, so this may not be the best of ideas.
Realistically, this is a very low risk to most people. However, session hijacking and packet sniffing via TCP was considered a low risk as well in the past.
One reason I go for BT mice over generic USB radio is the fact that BT traffic is encrypted once the devices are paired. Someone sniffing traffic would not be able to figure out your mouse patterns, or even worse take control of your mouse and start clicking on stuff.
Similar with a BT keyboard versus a wireless keyboard and either intercepting keystrokes or injecting them.
I wasn't sure from the TFA, but previous holo disks were WORM media, where they were intended for archiving.
With media this inexpensive, it would be a boon for both hospitals, but companies in general who have to archive everything, due to Sarbanes Oxley, HIPAA, CALEA, and other regulations.
What GE will need to work on, once this comes out in a standard cartridge format, is some type of autochanger that can reliably move media in and out. In days of yore where companies had WORM optical media, one loaded a library with 50-100 disks, and as they got full, labeled them, swapped them out for empty ones, and either stored them in a tape safe, or dropped them in a tub for Iron Mountain to pick up and store.
That is a pretty sweeping statement, similar to saying that all American companies can't lock their doors down.
This varies by department, organization, and sysadmin. A lot of US government divisions have intelligent, alert, and aware employees who do a good job at what they do. However, these people don't make the news.
This is one of the things with IT. If you do a good job, nobody notices. Its only if stuff fails is when people notice. Same thing with this mess.
This same thing can be said about hardware. If your hardware was compromised at the IC level, (say a certain string of gibberish would allow ring zero access) then no OS security would matter, and the only way to even slow this down would be a special hypervisor that intercepted every single assembly instruction... and even in this case, there would be ways to probably hide stuff with various variable and register states.
How about not cyber soldiers, but true IT professionals who know their field?
Security is not all about the technological side. A major part of security is dealing with social engineering. Another major part is dealing security needs of a department or organization. Security and infrastructure needs of a law firm with 5 workstations and a server are totally different from the security of a multi-location corporate environment. Security needs of a TS facility are absolutely different from an unclassified facility.
The "whiz kids" are an important part of this, but you also need security people who can handle not just finding the more exotic bugs, but be able to make sure that a department, enterprise, or organization are up to speed. You need people who can (for example) LART the reprobate who is in receiving and who is browsing pr0n on a workstation with the AV program disabled and IE's security set to "low" so he doesn't get asked to install IE controls that stand between him and his excitement.
Security takes a lot of puzzle pieces, and people with many talents.