It is my sincere hope that NFS based NAS will die. It is easily the worst possible solution for current networks when it comes to any situation where data is put on the share that is not acceptable to share to anyone with access to your entire network. The security is so awful that I'm amazed that auditors only have moderate language against it thus far. NFS V3 (which is all that most of the NAS vendors seem to support) security seems to roughly be the same as the r-services, meaning roughly that of a three foot chain link fence around a playground. It says please keep out, but that's all.
Oh, and as someone who has done real work on moderately high end Sun servers, anyone expecting five nines had better be prepared to spend a lot more than $5M for the solution. You listed six nines, which is even worse.
My experience with Linux has us on track to get an amazing 2.5 nines. We have had well over 12 hours of application downtime in the past eight months caused by still unexplained kernel panics that the vendor cannot identify if it is even hardware or software. It doesn't help that RHEL's IPSEC is so unstable by default as to fail several times a day. Took a lot of digging around to find a configuration change to stabilize that.
My experience is quite the opposite of yours. I'd gladly give up my 54 Linux boxes for this one application, and replace the 20 central nodes with 4-5 truly large boxes.
Underpowered zones I find to usually be the result of bad planning (way too much stacking). We use moderate sized boxes, not the baby Crays (E10k types), but things like what used to be the E6900.
These days, my hardware is Linux and I'm cursing the lack of hardware diagnostic tools, the low quality of the kernel, the inability of our standard middleware teams (Veritas/Symantec, Oracle, etc.) to support even minor kernel patches, etc.
No one solution works for every application. I have a few apps that work really well in a zone. Other applications require a standalone box, and Linux works great. Some of my most parallel apps, Linux was chosen by our vendor, and we're trying hard to find a reason not to throw the vendor and the boxes out the window. Application failures, kernel panics that the hardware and OS vendor can't tell us if they are even hardware or software caused, you name it.
Solaris 9, I agree was underpowered, relatively tame. Solaris 10 is a surprisingly major shift in operating approach. Some of the changes I think are good, some not. I'm still unconvinced that svcs is done correctly. Databases as the underlying structure for OS configuration I consider very dangerous because of the higher risk of corruption and increased difficulty in using unexpected or arbitrary tools to maintain consistency (AIX folks know what I'm talking about here.) But some of the ideas I find very appealing. That might be even more obvious when for home, I rejected Linux and bought a Sun workstation with Solaris 10. I was tired of supporting hardware on my own with no help. Sun's workstation at the time was bid lower than any equivalent hardware from anyone else that would submit a quote.
So when Sun or HP or even Red Hat issue an alert for a privilege escalation vulnerability to administrative rights, you presume that you are penetrated when you patch the box? That's not how things work.
Actually, very few black hats will take down servers or destroy them anymore. Public image destruction is an unfortunately common goal of malicious intrusion into a computer. Yes, many will attempt to obtain data for use. Another, unmentioned, major category of reason is to have a server to launch further attacks in order to hide behind.
Except he wasn't white hat at all. A white hat always gets permission in writing before taking action to even probe a selected server, nevermind actually break into it.
The fundamental rule of computer security I teach new system administrators is that there is no such thing as a secure computer. If the computer exists, it can be compromised. My team jokes that the secure computer is dismantled, each component piece melted down, then fired into the Sun. We used to think that dropping into various parts of the ocean was good enough, but they are getting too good at recovering data from the bottom of the ocean floor.
Because no server is ever secure, there are always attacks, vulnerabilities that exist on a box. Even of the known ones, some cannot be fixed due to layer 8 or 9 problems. In my line of work, we emphasize that just as important as keeping the integrity of the servers is knowing if the integrity is violated. Not all vulnerabilities can be reasonably stopped, some you just have to rely on detection.
Sending black hats through the legal system for possible jail time does lessen the threat, by definition. First, if convicted, the individual in question is eliminated from being a threat to your computers. Second, it serves to deter others who can learn from another's example. Randall Schwartz, no matter what you think of that case, deterred a lot of people from coming close to breaking into servers without written authorization. That severely lessened the threat to servers because people started realizing there are real threats, and that they needed an explicit okay in writing before doing such things.
However, sending them through the legal system isn't done with the end goal of reducing the threat, but of punishment for wrong actions. A system administrator who did not report up to appropriate management such a break-in for possible referral to the legal system would in ethical hot water themselves and trying to hide it.
True white hat crackers, more often known as authorized penetration teams in business, have strict limits on what they can do once they get in. Usually it is simple stuff to prove they could have done more. Often, they have strict monitoring of their actions to a secured server that they can't ready penetrate even if they wanted to.
There are intense negotiations prior to the work being done, clear authorization in writing, etc.
If Joe Random wanted to break into a server, they'd be refused. If the student presented a proposal in advance with appropriate safeguards to show how their actions would be limited and monitored, then a series of test servers could be set up.
This isn't ten years ago when there was still debate on the proper and ethical way to report discovered security issues without exploiting them. One reports the issue without ever coming close to exploiting it.
If they don't ask, by definition, it is malicious, because they are doing so without authorization, permission, or safeguard on their actions.
The cleanup cost of an unexploited vulnerability is relatively low. A few configuration changes, a few patches, all part of routine administration.
The cleanup cost of an exploited system, no matter what vulnerability was used, is tremendous. Heavy investigation to determine the scope of the penetration, the need to offline the systems while they are rebuilt from the ground up, etc.
Breaking into a server when you have legitimate reason to believe that you may have authorization but actually don't is bad enough. Breaking into a server when you cannot reasonably believe you are authorized to do so is pure black hat. "Damaging the box" is inherent to the break-in.
If the user trashed files, it wouldn't matter as much to the issue as you think, because they'd still be coming from backups.
Oh, the innocence of this post, the sheer innocence. System administration isn't easier today than it was fifteen years ago, but harder.
Ten years ago, junior admins on my team and dozens of teams like mine received emails that told them where to run useradd. Now, a script maintained by two senior admins will do it for them, including locking accounts when the user leaves the company or their supervisor does not revalidate the need for the account.
The constant complaint of my peers in primary system administration roles is that the required skill level has gone through the ceiling to even enter the field. Gone are the entry level areas because enterprise centralization has eliminated them. New technologies have introduced complexities that may not exist on the home hobby system, but are rather likely on the enterprise level.
Anyone who thinks that system administration is about using the pretty GUI to run useradd, I know better than to trust with the root GUIs (smitty, sam, admintool,...) that were in use ten years ago, because they're going to foul up the system in a way to violate the audit trail. With the exception of smit, the first thing I train junior SAs is never use the GUI because you'll just mess things up.
Don't presume these easements don't ever involve any compensation. In a case where I had reliable information on, the utility company (yes, it was AT&T) offered financial compensation to the property owner, a specific suggestion of where the easement would be placed as a very out of the way location, easily overlooked, and the option to decline.
The house I grew up in had a 4x4x2 (at least) big utility box on one corner of the lawn, don't recall if it was phone or power. That's where my parents chose to plant a couple bushes, along with the next door neighbors (was on the corner property). You could hardly see it from the sidewalk two feet away unless you were looking specifically for it. From the back it was readily accessible.
The utility companies aren't universally just dumping these on property without compensation. Depending on the local laws, it may be done that way in some areas, but I wouldn't presume it to be done that way everywhere.
scp creates a problem of securing the remote machine. Generally, I advise a SSH passthrough mechanism, using forced commands to restrict the writing to a filename chosen by the receiver and ensure that the account cannot be leveraged to copy other files, or eliminate the security protections and get a full shell. Since the key item of the fingerprint can be validated via out of band mechanism (telephone), it is feasible to ensure that the public key being installed is appropriate.
However, as we are talking about Sensitive Personal Information (SPI), the data should be encrypted at rest, not just in transit. While many have suggested GPG/PGP, that fails because in order for the data to ever be utilized, it has to be decrypted on disk and it will then stick around. Some have suggested truecrypt, which, when used where that works, is a good choice. The key answer depends on data not provided: platforms used by the different parties, direction of traffic, one time transfer or not, format the data currently exists in (is it in a database?), etc. For example, if this was a regular transfer and mainframes were involved, I'd advise using Connect:Direct with SecurePlus of data where the individual sensitive fields are encrypted. Commercial product, but sure beats the socks off anything else I've seen proposed for getting files reliably to mainframes. (And yes, that product is available for Windows and Unix).
The nice thing about many databases today is the fact that one can encrypt individual fields or columns of a tablespace. That provides a mechanism to ensure that the data remains encrypted and is only decrypted on an as needed basis.
Maybe because the headhunters aren't being told those as the skill set that is needed. They're asking for SAGE II (fairly junior) folks and not too many of those know VCS. Solaris 10? Wasn't on the list of requirements, just "Solaris". I can't tell you how many times I've passed up the option to interview there because I won't submit my resume unless I think I actually have the skills and it is for my level rather than some junior position. (And yes, I talked to a few of them about those positions that were advertised there. I passed on it for some reason or another, can't recall which, but it certainly wasn't Solaris or VCS.)
This brings up the standard series of rants about lousy headhunters and lousy HR folks giving headhunters bad information. Not too many junior folks know enough to force the headhunter to get more information.
Saying there is a Linux version is a little deceptive. I evaluated TrueCrypt for a project where disk encryption was a requirement. The environment was pure Linux. The documentation claimed that in order to create a partition, a Windows machine had to have access to the disk space in question, not an option in my case.
While it looked good on paper, I was unable to get beyond that basic requirement. In the end, we used cryptsetup which comes with RHAS 4 to create an encrypted volume. There are limitations, like the inability to change the key for the volume, and the fact that it is pure private key (At times I wish it used a public/private key system like GnuPG), but at least it actually works on Linux, with the added advantage of being a fully supported solution by the OS vendor, something that for some people, actually matters.
Somehow I suspect the credit card companies wouldn't like that idea. It would use the PAN in an area where it is not required and storing it (presumably) unencrypted.
Having gone through PCI audits, I agree they can be a nuisance, but mainly if you do not have an organization dedicated to audit response[1]. Responding to an audit requires professionals who actually work closely with every auditor, not just once a year, and are literally preparing for audits year round and are a central point for all audits. I found the PCI audit refreshing for the preciseness compared to the SOX audit which was more of a "hope the auditor interprets policy the exact same way you do."
The precise phrasing is to remove the most common problem in audits, vague requirements resulting in uneven interpretation from company to company. For example, it is no longer questionable if logs must be stored on a central log server, it is explicit. The preamble clearly spells out what servers are in scope. I don't have to guess anymore. Yes, I've been the one farmed out to a subsidiary to help them figure out ways to comply with some PCI requirements, but it was something of a "explain what we figured out that passed our audit, help them tweak it for their environment in a way likely to pass their audit." The newness of PCI is why people are rather nervous, that and the very draconian listed penalties. Frankly, the penalties need to be that strict to prevent larger companies from deciding it is cheaper to pay the fines than to comply. In a few more years, these cross-company security audits will become better understood by a larger group of administrators and managers and the methods of compliance will be better understood.
It really is primarily a case of good practice. It is very possible to comply without any use of commercial software or open source tools that aren't fairly well known and mature today.
[1]: Yes, I do work on an audit response/organizational security team.
Who said anything about logging in as root? You need to capture the data even if they log in as themselves and do a `sudo -s` or `su` so that they can do the types of SA work that is rather difficult in single sudo commands, the kind of thing I do literally all the time.
sudo is a good tool, but it has definite limitations.
A lot of SOX compliance boils down to "follow good security practice, have good security policy". Yes, a lot of companies have run into hellish situations, often they are the fault of the company for writing impossible policies (or in some cases, no policy at all), or simply not following what anyone would realistically describe as good practice in security. I've seen many shops that took the view that security was unimportant, they simply built it into their model because the risk was rarely on the company. SOX forces companies to do things correctly for a change. To me, SOX has been the biggest boon in encouraging better security practice by system administrators and management that I've seen in over ten years.
For the most part I agree with you, but I don't want to downplay that there are some real technical hurdles in the PCIDSS requirements that do require actual creativity or money to solve at this time. To me, the hardest problem to solve is the "command line history of all commands executed as root". Keystroke loggers log too much, as do screen scrape loggers.
One nice thing to see would be a modification of the shell that will log to a specified logfile the command history if the effective UID is the targeted entry, not just the login name. Setting it in an auditable file also allows one to detect when it is bypassed (running a different shell, etc.)
But yes, most of the compliance points in PCI-DSS and in SOX boil down to "follow good security practice" and "have sane policy", making compliance easy if your management is willing to ensure that security is a concern and policy reflects a realistic approach.
sudosh logs all output, and all keystrokes, not a permissible option because if the user for some reason types or views a password or payment card number, that data MUST be encrypted while on disk (sorry, don't recall the section number in the 1.1 PCIDSS offhand). RBAC is for limiting commands, but not for logging. Putting the root password in a sealed envelope is also not a realistic option for many locations considering geographic scattering which means the SAs are rarely in the same city, nevermind building as each other or the boxes. Virtual envelope systems that work have yet to be proven out to me.
When looking at PCI requirements, one cannot simply ignore the inconvenient items. A reliable method of capturing EUID 0 command history is a difficult problem. I won't say impossible because there are a few ways to do it, but they usually rely on an attestation of the SA that they are not trying to subvert their HISTFILE or some similar method. Capturing too much data is actually worse than capturing too little in some ways.
Append only files have not been required in my experience. What is required is that there be no ability to overwrite a previously written file by the team that is sending the log data.
The one is a way to get the other... at least partially. Physical and electronic security and partitioning of roles gets you the rest of the way.
Agreed. I just find that the lack of support for append only files makes it hard to use as a solution on most platforms.
This can be done a number of ways, but the easiest method is to transmit the data in a way that the server chooses the filename, not the client.
I'm not sure how filenames enter into it, since you don't give the application people access to the log host anyway.
The solution I'm familiar with receives a datastream and writes to a file. If I allowed the sender to select a filename to write, they could hypothetically corrupt or worse, delete log data. It's a little easier to set up than most solutions to transmit the data securely.
syslog works for most data, but not all. Linux is one of the only Unix based systems that puts sulog through syslog. The failed logins log is much more difficult, as is the wtmp data.
There is a "syslog Working Group" that's working on that and other problems. I don't know if syslogng supports any of their proposals yet, though.
I don't see how this can help. The issue isn't so much how to handle data that has gone into the syslog stream, but how to grab critical log data that doesn't normally enter into the syslog mechanism in the first place. Maybe I am missing something? I am however interested in hearing more about the working group, especially if they are likely to be able to update the standards so that the commercial Unix vendors will be able to seriously implement an improved syslog. Sun's comment on why Solaris 10 didn't have a better syslog was they wanted to, but they felt bound by POSIX. True or not, there is at least the impression by some of the vendors that they aren't allowed to use a better syslog by default. Replacing every single box's syslog would be problematic in larger shops.
As to writing periodically to a optical media, I wouldn't worry quite so much about that.
It's very important to be able to talk about your risk exposure profile. When you can say that the exposure to electronic subversion of the logs (regardless of how hard you make that, via electronic security) ends when the data is written to optical disk, you can make a much stronger case for the data being functionally write-once.
I wouldn't say the risk ends, just that the risk for modification effectively ends. But I very much agree, one needs to look at the threat profile.
I would instead worry more about the encrypting all that security data while in network transit.
That would only be necessary if you transmit sensitive data in the logs. For example, if a healthcare company wrote client data to their in-house application server's logs, then the logs would have to be subject to the same security constraints as every other piece of sensitive data. This is as far as I know, but my PCI exposure is tangential, and I haven't read the requirements first-hand.
Since the logs in question are security logs, my inclination is to always encrypt them just in case sensitive data does enter it. It need not be true credit card data, it could be other items that increase attack exposure. Knee-jerk? Maybe. One thing to think about though, the security logs of one box may not be critical enough to justify encrypting, but the security logs of lots of systems together may be that sensitive.
Authenticity is also an issue to be concerned with. How do you know that the event that got inserted into the log really came from that box, and not some ra
Append only files have not been required in my experience. What is required is that there be no ability to overwrite a previously written file by the team that is sending the log data. This can be done a number of ways, but the easiest method is to transmit the data in a way that the server chooses the filename, not the client. Add a date string into the filename and you can (with a few other details I've worked at but am here waving a wand at) avoid the problem.
syslog works for most data, but not all. Linux is one of the only Unix based systems that puts sulog through syslog. The failed logins log is much more difficult, as is the wtmp data. wtmp data is especially annoying as it is one of the only ways to semi-reliably record both login and logout regardless of login type (including ssh), and can't really handle real time data streaming. The other annoying item is the command line history of all commands with EUID 0. I'm hoping to hear some news soon on a solution to that problem, but it is really difficult, especially since a lot of SAs become root via `sudo -s` or `su` (as opposed to `su -`, which would not modify their HISTFILE variable. Many root shells do not support direct sending of HISTFILE over the network.
As to writing periodically to a optical media, I wouldn't worry quite so much about that. I would instead worry more about the encrypting all that security data while in network transit. (Sorry, can't recall if that is a firm requirement of PCIDSS 1.1 or not). Unfortunately, this makes use of syslog a less trivial solution. Authenticity is also an issue to be concerned with. How do you know that the event that got inserted into the log really came from that box, and not some random other server? Traditionally, syslog has not concerned itself with such issues, but a PCI system may care a great deal.
Once the data is on the central logging host, it is already in a state that the author of the data (the SAs for the PCI impacted box) cannot modify it. That eliminates at least in the interpretation of PCI I've been working on, the need for writing to optical media. Immutable is not so much immutable by anyone, but immutable by the server in question.
The point of the central copy of the logs is so that modification on either side can be readily detected and investigated. But if you cannot trust your central log host to have an accurate copy of the logs because you are receiving log data from anyone who chooses to pretend they are your PCI impacted server, then your central log host does not give you as much value as it may seem. The audit requirements aren't just for making lives miserable, they usually have a valid point behind them.
When working with PCI, know which DSS you are on, 1.0 or 1.1. (I don't know the release schedule for the next PCIDSS.) The requirements do differ, as do even the interpretations. Reference https://www.pcisecuritystandards.org/ for the information.
They'll give that issue the same attention they did when they passed laws mandating that school buses have omni-directional strobe lights on them that are on as long as the engine is running. In other words, don't expect lawmakers to care at all.
Slashdot Mirror
It is my sincere hope that NFS based NAS will die. It is easily the worst possible solution for current networks when it comes to any situation where data is put on the share that is not acceptable to share to anyone with access to your entire network. The security is so awful that I'm amazed that auditors only have moderate language against it thus far. NFS V3 (which is all that most of the NAS vendors seem to support) security seems to roughly be the same as the r-services, meaning roughly that of a three foot chain link fence around a playground. It says please keep out, but that's all.
Oh, and as someone who has done real work on moderately high end Sun servers, anyone expecting five nines had better be prepared to spend a lot more than $5M for the solution. You listed six nines, which is even worse.
My experience with Linux has us on track to get an amazing 2.5 nines. We have had well over 12 hours of application downtime in the past eight months caused by still unexplained kernel panics that the vendor cannot identify if it is even hardware or software. It doesn't help that RHEL's IPSEC is so unstable by default as to fail several times a day. Took a lot of digging around to find a configuration change to stabilize that.
My experience is quite the opposite of yours. I'd gladly give up my 54 Linux boxes for this one application, and replace the 20 central nodes with 4-5 truly large boxes.
Underpowered zones I find to usually be the result of bad planning (way too much stacking). We use moderate sized boxes, not the baby Crays (E10k types), but things like what used to be the E6900.
These days, my hardware is Linux and I'm cursing the lack of hardware diagnostic tools, the low quality of the kernel, the inability of our standard middleware teams (Veritas/Symantec, Oracle, etc.) to support even minor kernel patches, etc.
No one solution works for every application. I have a few apps that work really well in a zone. Other applications require a standalone box, and Linux works great. Some of my most parallel apps, Linux was chosen by our vendor, and we're trying hard to find a reason not to throw the vendor and the boxes out the window. Application failures, kernel panics that the hardware and OS vendor can't tell us if they are even hardware or software caused, you name it.
Solaris 9, I agree was underpowered, relatively tame. Solaris 10 is a surprisingly major shift in operating approach. Some of the changes I think are good, some not. I'm still unconvinced that svcs is done correctly. Databases as the underlying structure for OS configuration I consider very dangerous because of the higher risk of corruption and increased difficulty in using unexpected or arbitrary tools to maintain consistency (AIX folks know what I'm talking about here.) But some of the ideas I find very appealing. That might be even more obvious when for home, I rejected Linux and bought a Sun workstation with Solaris 10. I was tired of supporting hardware on my own with no help. Sun's workstation at the time was bid lower than any equivalent hardware from anyone else that would submit a quote.
So when Sun or HP or even Red Hat issue an alert for a privilege escalation vulnerability to administrative rights, you presume that you are penetrated when you patch the box? That's not how things work.
Actually, very few black hats will take down servers or destroy them anymore. Public image destruction is an unfortunately common goal of malicious intrusion into a computer. Yes, many will attempt to obtain data for use. Another, unmentioned, major category of reason is to have a server to launch further attacks in order to hide behind.
Except he wasn't white hat at all. A white hat always gets permission in writing before taking action to even probe a selected server, nevermind actually break into it.
This is just ridiculous.
The fundamental rule of computer security I teach new system administrators is that there is no such thing as a secure computer. If the computer exists, it can be compromised. My team jokes that the secure computer is dismantled, each component piece melted down, then fired into the Sun. We used to think that dropping into various parts of the ocean was good enough, but they are getting too good at recovering data from the bottom of the ocean floor.
Because no server is ever secure, there are always attacks, vulnerabilities that exist on a box. Even of the known ones, some cannot be fixed due to layer 8 or 9 problems. In my line of work, we emphasize that just as important as keeping the integrity of the servers is knowing if the integrity is violated. Not all vulnerabilities can be reasonably stopped, some you just have to rely on detection.
Sending black hats through the legal system for possible jail time does lessen the threat, by definition. First, if convicted, the individual in question is eliminated from being a threat to your computers. Second, it serves to deter others who can learn from another's example. Randall Schwartz, no matter what you think of that case, deterred a lot of people from coming close to breaking into servers without written authorization. That severely lessened the threat to servers because people started realizing there are real threats, and that they needed an explicit okay in writing before doing such things.
However, sending them through the legal system isn't done with the end goal of reducing the threat, but of punishment for wrong actions. A system administrator who did not report up to appropriate management such a break-in for possible referral to the legal system would in ethical hot water themselves and trying to hide it.
True white hat crackers, more often known as authorized penetration teams in business, have strict limits on what they can do once they get in. Usually it is simple stuff to prove they could have done more. Often, they have strict monitoring of their actions to a secured server that they can't ready penetrate even if they wanted to.
There are intense negotiations prior to the work being done, clear authorization in writing, etc.
If Joe Random wanted to break into a server, they'd be refused. If the student presented a proposal in advance with appropriate safeguards to show how their actions would be limited and monitored, then a series of test servers could be set up.
This isn't ten years ago when there was still debate on the proper and ethical way to report discovered security issues without exploiting them. One reports the issue without ever coming close to exploiting it.
If they don't ask, by definition, it is malicious, because they are doing so without authorization, permission, or safeguard on their actions.
The cleanup cost of an unexploited vulnerability is relatively low. A few configuration changes, a few patches, all part of routine administration.
The cleanup cost of an exploited system, no matter what vulnerability was used, is tremendous. Heavy investigation to determine the scope of the penetration, the need to offline the systems while they are rebuilt from the ground up, etc.
Breaking into a server when you have legitimate reason to believe that you may have authorization but actually don't is bad enough. Breaking into a server when you cannot reasonably believe you are authorized to do so is pure black hat. "Damaging the box" is inherent to the break-in.
If the user trashed files, it wouldn't matter as much to the issue as you think, because they'd still be coming from backups.
Oh, the innocence of this post, the sheer innocence. System administration isn't easier today than it was fifteen years ago, but harder.
Ten years ago, junior admins on my team and dozens of teams like mine received emails that told them where to run useradd. Now, a script maintained by two senior admins will do it for them, including locking accounts when the user leaves the company or their supervisor does not revalidate the need for the account.
The constant complaint of my peers in primary system administration roles is that the required skill level has gone through the ceiling to even enter the field. Gone are the entry level areas because enterprise centralization has eliminated them. New technologies have introduced complexities that may not exist on the home hobby system, but are rather likely on the enterprise level.
Anyone who thinks that system administration is about using the pretty GUI to run useradd, I know better than to trust with the root GUIs (smitty, sam, admintool, ...) that were in use ten years ago, because they're going to foul up the system in a way to violate the audit trail. With the exception of smit, the first thing I train junior SAs is never use the GUI because you'll just mess things up.
Don't presume these easements don't ever involve any compensation. In a case where I had reliable information on, the utility company (yes, it was AT&T) offered financial compensation to the property owner, a specific suggestion of where the easement would be placed as a very out of the way location, easily overlooked, and the option to decline.
The house I grew up in had a 4x4x2 (at least) big utility box on one corner of the lawn, don't recall if it was phone or power. That's where my parents chose to plant a couple bushes, along with the next door neighbors (was on the corner property). You could hardly see it from the sidewalk two feet away unless you were looking specifically for it. From the back it was readily accessible.
The utility companies aren't universally just dumping these on property without compensation. Depending on the local laws, it may be done that way in some areas, but I wouldn't presume it to be done that way everywhere.
Sounds about typical for HP. Back many years ago when I was primarily an HP-UX SA, excessive packaging was the norm as well.
scp creates a problem of securing the remote machine. Generally, I advise a SSH passthrough mechanism, using forced commands to restrict the writing to a filename chosen by the receiver and ensure that the account cannot be leveraged to copy other files, or eliminate the security protections and get a full shell. Since the key item of the fingerprint can be validated via out of band mechanism (telephone), it is feasible to ensure that the public key being installed is appropriate.
However, as we are talking about Sensitive Personal Information (SPI), the data should be encrypted at rest, not just in transit. While many have suggested GPG/PGP, that fails because in order for the data to ever be utilized, it has to be decrypted on disk and it will then stick around. Some have suggested truecrypt, which, when used where that works, is a good choice. The key answer depends on data not provided: platforms used by the different parties, direction of traffic, one time transfer or not, format the data currently exists in (is it in a database?), etc. For example, if this was a regular transfer and mainframes were involved, I'd advise using Connect:Direct with SecurePlus of data where the individual sensitive fields are encrypted. Commercial product, but sure beats the socks off anything else I've seen proposed for getting files reliably to mainframes. (And yes, that product is available for Windows and Unix).
The nice thing about many databases today is the fact that one can encrypt individual fields or columns of a tablespace. That provides a mechanism to ensure that the data remains encrypted and is only decrypted on an as needed basis.
OpenSSH 5.0 has chroot and sftp only accounts support in the sshd_config file.
Trick-Or-Treating during daylight makes as much sense as holding 4th of July fireworks during daylight. Both require the night.
Maybe because the headhunters aren't being told those as the skill set that is needed. They're asking for SAGE II (fairly junior) folks and not too many of those know VCS. Solaris 10? Wasn't on the list of requirements, just "Solaris". I can't tell you how many times I've passed up the option to interview there because I won't submit my resume unless I think I actually have the skills and it is for my level rather than some junior position. (And yes, I talked to a few of them about those positions that were advertised there. I passed on it for some reason or another, can't recall which, but it certainly wasn't Solaris or VCS.)
This brings up the standard series of rants about lousy headhunters and lousy HR folks giving headhunters bad information. Not too many junior folks know enough to force the headhunter to get more information.
Saying there is a Linux version is a little deceptive. I evaluated TrueCrypt for a project where disk encryption was a requirement. The environment was pure Linux. The documentation claimed that in order to create a partition, a Windows machine had to have access to the disk space in question, not an option in my case.
While it looked good on paper, I was unable to get beyond that basic requirement. In the end, we used cryptsetup which comes with RHAS 4 to create an encrypted volume. There are limitations, like the inability to change the key for the volume, and the fact that it is pure private key (At times I wish it used a public/private key system like GnuPG), but at least it actually works on Linux, with the added advantage of being a fully supported solution by the OS vendor, something that for some people, actually matters.
Somehow I suspect the credit card companies wouldn't like that idea. It would use the PAN in an area where it is not required and storing it (presumably) unencrypted.
Having gone through PCI audits, I agree they can be a nuisance, but mainly if you do not have an organization dedicated to audit response[1]. Responding to an audit requires professionals who actually work closely with every auditor, not just once a year, and are literally preparing for audits year round and are a central point for all audits. I found the PCI audit refreshing for the preciseness compared to the SOX audit which was more of a "hope the auditor interprets policy the exact same way you do."
The precise phrasing is to remove the most common problem in audits, vague requirements resulting in uneven interpretation from company to company. For example, it is no longer questionable if logs must be stored on a central log server, it is explicit. The preamble clearly spells out what servers are in scope. I don't have to guess anymore. Yes, I've been the one farmed out to a subsidiary to help them figure out ways to comply with some PCI requirements, but it was something of a "explain what we figured out that passed our audit, help them tweak it for their environment in a way likely to pass their audit." The newness of PCI is why people are rather nervous, that and the very draconian listed penalties. Frankly, the penalties need to be that strict to prevent larger companies from deciding it is cheaper to pay the fines than to comply. In a few more years, these cross-company security audits will become better understood by a larger group of administrators and managers and the methods of compliance will be better understood.
It really is primarily a case of good practice. It is very possible to comply without any use of commercial software or open source tools that aren't fairly well known and mature today.
[1]: Yes, I do work on an audit response/organizational security team.
Who said anything about logging in as root? You need to capture the data even if they log in as themselves and do a `sudo -s` or `su` so that they can do the types of SA work that is rather difficult in single sudo commands, the kind of thing I do literally all the time.
sudo is a good tool, but it has definite limitations.
A lot of SOX compliance boils down to "follow good security practice, have good security policy". Yes, a lot of companies have run into hellish situations, often they are the fault of the company for writing impossible policies (or in some cases, no policy at all), or simply not following what anyone would realistically describe as good practice in security. I've seen many shops that took the view that security was unimportant, they simply built it into their model because the risk was rarely on the company. SOX forces companies to do things correctly for a change. To me, SOX has been the biggest boon in encouraging better security practice by system administrators and management that I've seen in over ten years.
For the most part I agree with you, but I don't want to downplay that there are some real technical hurdles in the PCIDSS requirements that do require actual creativity or money to solve at this time. To me, the hardest problem to solve is the "command line history of all commands executed as root". Keystroke loggers log too much, as do screen scrape loggers.
One nice thing to see would be a modification of the shell that will log to a specified logfile the command history if the effective UID is the targeted entry, not just the login name. Setting it in an auditable file also allows one to detect when it is bypassed (running a different shell, etc.)
But yes, most of the compliance points in PCI-DSS and in SOX boil down to "follow good security practice" and "have sane policy", making compliance easy if your management is willing to ensure that security is a concern and policy reflects a realistic approach.
sudosh logs all output, and all keystrokes, not a permissible option because if the user for some reason types or views a password or payment card number, that data MUST be encrypted while on disk (sorry, don't recall the section number in the 1.1 PCIDSS offhand). RBAC is for limiting commands, but not for logging. Putting the root password in a sealed envelope is also not a realistic option for many locations considering geographic scattering which means the SAs are rarely in the same city, nevermind building as each other or the boxes. Virtual envelope systems that work have yet to be proven out to me.
When looking at PCI requirements, one cannot simply ignore the inconvenient items. A reliable method of capturing EUID 0 command history is a difficult problem. I won't say impossible because there are a few ways to do it, but they usually rely on an attestation of the SA that they are not trying to subvert their HISTFILE or some similar method. Capturing too much data is actually worse than capturing too little in some ways.
Append only files have not been required in my experience. What is required is that there be no ability to overwrite a previously written file by the team that is sending the log data.
The one is a way to get the other... at least partially. Physical and electronic security and partitioning of roles gets you the rest of the way.
Agreed. I just find that the lack of support for append only files makes it hard to use as a solution on most platforms.
This can be done a number of ways, but the easiest method is to transmit the data in a way that the server chooses the filename, not the client.
I'm not sure how filenames enter into it, since you don't give the application people access to the log host anyway.
The solution I'm familiar with receives a datastream and writes to a file. If I allowed the sender to select a filename to write, they could hypothetically corrupt or worse, delete log data. It's a little easier to set up than most solutions to transmit the data securely.
syslog works for most data, but not all. Linux is one of the only Unix based systems that puts sulog through syslog. The failed logins log is much more difficult, as is the wtmp data.
There is a "syslog Working Group" that's working on that and other problems. I don't know if syslogng supports any of their proposals yet, though.
I don't see how this can help. The issue isn't so much how to handle data that has gone into the syslog stream, but how to grab critical log data that doesn't normally enter into the syslog mechanism in the first place. Maybe I am missing something? I am however interested in hearing more about the working group, especially if they are likely to be able to update the standards so that the commercial Unix vendors will be able to seriously implement an improved syslog. Sun's comment on why Solaris 10 didn't have a better syslog was they wanted to, but they felt bound by POSIX. True or not, there is at least the impression by some of the vendors that they aren't allowed to use a better syslog by default. Replacing every single box's syslog would be problematic in larger shops.
As to writing periodically to a optical media, I wouldn't worry quite so much about that.
It's very important to be able to talk about your risk exposure profile. When you can say that the exposure to electronic subversion of the logs (regardless of how hard you make that, via electronic security) ends when the data is written to optical disk, you can make a much stronger case for the data being functionally write-once.
I wouldn't say the risk ends, just that the risk for modification effectively ends. But I very much agree, one needs to look at the threat profile.
I would instead worry more about the encrypting all that security data while in network transit.
That would only be necessary if you transmit sensitive data in the logs. For example, if a healthcare company wrote client data to their in-house application server's logs, then the logs would have to be subject to the same security constraints as every other piece of sensitive data. This is as far as I know, but my PCI exposure is tangential, and I haven't read the requirements first-hand.
Since the logs in question are security logs, my inclination is to always encrypt them just in case sensitive data does enter it. It need not be true credit card data, it could be other items that increase attack exposure. Knee-jerk? Maybe. One thing to think about though, the security logs of one box may not be critical enough to justify encrypting, but the security logs of lots of systems together may be that sensitive.
Authenticity is also an issue to be concerned with. How do you know that the event that got inserted into the log really came from that box, and not some ra
Append only files have not been required in my experience. What is required is that there be no ability to overwrite a previously written file by the team that is sending the log data. This can be done a number of ways, but the easiest method is to transmit the data in a way that the server chooses the filename, not the client. Add a date string into the filename and you can (with a few other details I've worked at but am here waving a wand at) avoid the problem.
syslog works for most data, but not all. Linux is one of the only Unix based systems that puts sulog through syslog. The failed logins log is much more difficult, as is the wtmp data. wtmp data is especially annoying as it is one of the only ways to semi-reliably record both login and logout regardless of login type (including ssh), and can't really handle real time data streaming. The other annoying item is the command line history of all commands with EUID 0. I'm hoping to hear some news soon on a solution to that problem, but it is really difficult, especially since a lot of SAs become root via `sudo -s` or `su` (as opposed to `su -`, which would not modify their HISTFILE variable. Many root shells do not support direct sending of HISTFILE over the network.
As to writing periodically to a optical media, I wouldn't worry quite so much about that. I would instead worry more about the encrypting all that security data while in network transit. (Sorry, can't recall if that is a firm requirement of PCIDSS 1.1 or not). Unfortunately, this makes use of syslog a less trivial solution. Authenticity is also an issue to be concerned with. How do you know that the event that got inserted into the log really came from that box, and not some random other server? Traditionally, syslog has not concerned itself with such issues, but a PCI system may care a great deal.
Once the data is on the central logging host, it is already in a state that the author of the data (the SAs for the PCI impacted box) cannot modify it. That eliminates at least in the interpretation of PCI I've been working on, the need for writing to optical media. Immutable is not so much immutable by anyone, but immutable by the server in question.
The point of the central copy of the logs is so that modification on either side can be readily detected and investigated. But if you cannot trust your central log host to have an accurate copy of the logs because you are receiving log data from anyone who chooses to pretend they are your PCI impacted server, then your central log host does not give you as much value as it may seem. The audit requirements aren't just for making lives miserable, they usually have a valid point behind them.
When working with PCI, know which DSS you are on, 1.0 or 1.1. (I don't know the release schedule for the next PCIDSS.) The requirements do differ, as do even the interpretations. Reference https://www.pcisecuritystandards.org/ for the information.
They'll give that issue the same attention they did when they passed laws mandating that school buses have omni-directional strobe lights on them that are on as long as the engine is running. In other words, don't expect lawmakers to care at all.