What is this employment contract you speak of? I keep hearing everyone talk about it, but I've never had to sign any such contract except for a side job I did once that was a single piece of work custom built for the company with no need to reuse.
Solaris had a long standing published support policy. By that policy, Solaris 9 should still be supported until two years after Solaris 11 ships. That got summarily changed.
I lost track of how many times Red Hat and HP sent changed dates on their enterprise OS end of support dates. "For the next year" isn't good enough when I've seen vendors suddenly change their mind and announce EoSL within eighteen months. In a large center, it can take longer than that to migrate with no end user impact.
Security culture is something that either is present in a large organization, or it isn't. The evidence suggests that Sony did not take security seriously in its projects until the series of attacks. Once that culture of insecurity is present, it takes years to undo. Think about how long it has taken Microsoft to shed even part of their image of insecurity.
Projects often need to be rewritten from the ground up to actually permit something remotely resembling security. Attackers are using far more sophisticated techniques, and Sony, probably like many other large companies, appears to have gotten stuck with an attitude about security stuck in the late 1980s.
I don't seriously expect Sony to truly recover for at least eight more months, and that's assuming a serious shift in their security culture. If you want to be an observer, look for updates to security advisories from major audit and assessment organizations (e.g. PCI). That will give a clue as to what really went wrong on a fundamental level.
Actually, the ad campaign included a lot more. The random soldier telling the wrong person that they were deploying with their unit that night, the dock worker who comments in a bar that a particular ship came back heavily damaged and would be in port for at least a month. It was aimed at people all over, who might not realize at first what they knew could be valuable in intelligence.
The Q&A linked from the summary isn't cryptographic researchers communicating with each other, but speaking specifically to the public saying how terrible this is. More than one statement is made about real world exploitability and how vulnerable the world is.
As for ECDSA, I've seen extremely few implementations that used it, but I'm focused on the OS side, not the application side, so maybe apps use it more than I realize.
This sounds like another the sky is falling alert. That alone makes me suspicious.
I'm not exactly an expert on this, but reading it, I see several assumptions built in that seem at best infeasible. First, while they admit that they can do it on a LAN, they admit that it is much harder, and over a larger or busier network crossing multiple routers, this may not be feasible. Second, they seem to believe that "cloud computing" makes it more feasible because they believe the odds of being stacked on the same physical server as your target is good.
I'm not by any means saying that they haven't identified a weakness that needs to be fixed, but right now, I'd need more to accept their claim of how vulnerable everyone is to this.
Just for fun, I tried out that tool. I plugged in the symptoms I had when I cracked a rib. When I went to the doctor, the nurse diagnosed me before I even got to the exam room based just on watching me walk and hearing where the pain was. The software didn't even begin to ask the right questions, and assigned a 94% probability of something completely unrelated.
I also tried plugging in the symptoms I had a number of years back before I realized I had asthma. It's diagnosis was for several possibilities, none better than 24%. However, a trained doctor, hearing me cough just once immediately recognized it as an asthma specific cough pattern.
So no, I wouldn't trust that tool over common sense, not even close.
I've never used an ATM for banking. My bank has branches in all the local grocery stores, and is open until at least six in the evening every week day. Saturday mornings, it is also open.
I've never had unwanted solicitations of services. The only time I was offered new services was when I asked questions indicating I was interested in such offers (like asking about online banking and they showed me information on online billpay).
I've never had to pay fees for my bank. They pay me for holding my money so that they can make loans to others. (Okay, so my interest rate is very low these days, it once was much higher).
I don't go into the physical bank even once a month, but when I do, they recognize me, and are genuinely friendly. If I have an odd question, they are more than happy to help, such as when my employer pushed me to a high deductible plan and I wanted to ask about my bank's HSA offering.
The idea of requiring me to only work with a computer is alien to me. I've done this with a few separate banks, and never had the problems others describe here.
Speaking as an outsider who has worked on PCI for the last several years.
There are a few ways this could happen. Sony could have focused on the sampled systems and forgotten another system. They may have been compliant at the time of the assessment and then allowed compliance to slip. There may have been a mitigating control on a non-compliance, accepted by the QSA, which turned out to not be as strong as believed. Or it may have been as strong as believed and caught the intrusion.
There is too much we don't know at this point. Now that it is confirmed that there was a chance of exposure of credit card numbers, the silence makes a lot of sense. There's a whole set of procedures to follow if you believe payment card numbers have been compromised.
What is likely to happen is if it is confirmed that credit card information was compromised, then there will be an investigation by the payment card industry into the source of the incident. This will then result likely in updated guidance for anyone who does credit card transactions that covers the area of the breach. Logging will be reemphasized to help detect attacks after the fact. (It always is).
Re:RTFA? Oh right you didn't.
on
Is Sugar Toxic?
·
· Score: 1
And here it takes me nine minutes to get tea. One minute to find a mug and put water in it and start microwaving it. Two minutes to microwave, six minutes to steep. Enjoy hot. My wife's tea is faster (three minute brew). Brew time depends on the type of tea of course. If you really want ice tea, use twice as much tea for the volume, and then double the volume using ice (standard recipe I was taught from cook books and better tea shops).
I've seen unsweetened tea dispensers at plenty of restaurants in my area and where I grew up, and yes, I do consider anything in Texas the Deep South. It may not seem so politically, but the cuisine has distinctive southern aspects, such as beverage choices.
Most green teas I've had are just as bad as the lousy cheap tea available in restaurants here. Brewed at the wrong temperature, the wrong strength, the wrong time, using the cheapest possible tea fannings (dust). I've had good tea at restaurants, but it doesn't come from a soda style dispenser. When I go into a tea shop to sample their teas, I can tell when a tea has been sitting for too long by the flavor.
Actually, 0 C is just cool enough to stop wearing short pants and a t-shirt if you are from Minnesota.
Re:RTFA? Oh right you didn't.
on
Is Sugar Toxic?
·
· Score: 2
Move out of the deep South. Unsweetened tea is common where I am, and also was common in the DC area where I grew up. It was crappy stuff, something I can't bring myself to drink because of how bad it tastes, but it is unsweetened tea. It took me years to learn how to brew tea and realize that the problem is restaurants are afraid of boiling water and thus brew black teas meant for seeping in water that is initially at a boiling temperature, at temperatures more suitable for delicate white or green teas, 140 F or less. To top it off, they don't even understand brew times up here.
Cheap amber oolong seems easy to find at those hole in the wall Chinese restaurants scattered everywhere, usually some form of teabag oolong brewed in a specialty tea brewing device that will keep a decent temperature for that tea, but don't try a black tea in those things. Those teas are never sweetened unless you add sugar at the table.
If you are looking for tea bags, most grocers I've seen have at least cheap, lousy teabags.
And yes, I buy real tea from a specialty store, but I do realize what is out there in tea, and in an emergency can make something I can at least stand to drink.
My observations match your references, everyone thinks they are eating the "right amount" to maintain their weight, no matter how much or little they eat. Very good kitchen scales (with.1 oz accuracy) are a must. As a bonus, this makes it easier to measure out the right amount of tea. And yes, my anecdote is that even people who eat too little to maintain their weight think they are eating the right amount.
This whole nonsense about sugar is just the latest extension of the craze diets that want to blame weight gain on something, anything other than eating more calories than used over time.
I suppose focusing on this is just the latest pendulum swing from the concern over children (and some adults) refusing to eat enough because they thought they would be too fat.
Here's how we solved that problem. All access to root (except for documented emergencies) is done by sudo to a logging shell. The sudo invocation records who invoked that shell on what TTY. The logging shell, which logs off-host in real time, records the tty in addition to the timestamp and command (and euid). Then we can correlate from the sudo to identify "this is the shell history session for this user starting at this time."
My cfengine policy clears all those shell aliases and color codings on my RHEL boxes. Unfortunately, the HP-UX folks love their aliases. I can't count how often I watch someone type ll as an alias for ls -l and wonder why it doesn't work on a non-HP-UX box.
The -i flag of sudo isn't available on many of the versions of sudo I've used over the past many years. (No fair looking back when the -i flag was introduced). We used the -s flag instead.
Trust is a dirty word in audits. I don't care how much you think you can trust someone, without auditing, it's just guesswork. The PCI certification, 10.2.2 requires logging actions taken with administrative privilege. That means not just the command to take a root shell, but what the user ran beneath that.
It's very common for sudo to log to syslog. It's also very common for syslog to log in real time off-host. The user may break the logging trail, but they won't hide the command they ran to break the logging trail.
Slashdot Mirror
awk instead of cut. How many people have gotten used to
ps -ef | awk '/foo/ { print $1,$4}'
And that's not even fancy awk scripting.
It also has the advantage of being standardized (Always use /usr/xpg4/bin/awk on Solaris, not /usr/bin/awk)
Gray 17 is missing, the Garibaldi parts, are worse. (Marcus's part of that episode aren't bad).
What is this employment contract you speak of? I keep hearing everyone talk about it, but I've never had to sign any such contract except for a side job I did once that was a single piece of work custom built for the company with no need to reuse.
Oh, you mean like HP-UX, Solaris and RHEL?
Solaris had a long standing published support policy. By that policy, Solaris 9 should still be supported until two years after Solaris 11 ships. That got summarily changed.
I lost track of how many times Red Hat and HP sent changed dates on their enterprise OS end of support dates. "For the next year" isn't good enough when I've seen vendors suddenly change their mind and announce EoSL within eighteen months. In a large center, it can take longer than that to migrate with no end user impact.
Some application vendors are even worse.
Security culture is something that either is present in a large organization, or it isn't. The evidence suggests that Sony did not take security seriously in its projects until the series of attacks. Once that culture of insecurity is present, it takes years to undo. Think about how long it has taken Microsoft to shed even part of their image of insecurity.
Projects often need to be rewritten from the ground up to actually permit something remotely resembling security. Attackers are using far more sophisticated techniques, and Sony, probably like many other large companies, appears to have gotten stuck with an attitude about security stuck in the late 1980s.
I don't seriously expect Sony to truly recover for at least eight more months, and that's assuming a serious shift in their security culture. If you want to be an observer, look for updates to security advisories from major audit and assessment organizations (e.g. PCI). That will give a clue as to what really went wrong on a fundamental level.
The comment that there will be no install media for OS X 10.7 is a show stopper to me.
Actually, the ad campaign included a lot more. The random soldier telling the wrong person that they were deploying with their unit that night, the dock worker who comments in a bar that a particular ship came back heavily damaged and would be in port for at least a month. It was aimed at people all over, who might not realize at first what they knew could be valuable in intelligence.
The Q&A linked from the summary isn't cryptographic researchers communicating with each other, but speaking specifically to the public saying how terrible this is. More than one statement is made about real world exploitability and how vulnerable the world is.
Don't tell me that I'm the only one who was reminded of the classic posters during World War II: Loose lips sink ships!
That still impacts the risk factor.
As for ECDSA, I've seen extremely few implementations that used it, but I'm focused on the OS side, not the application side, so maybe apps use it more than I realize.
This sounds like another the sky is falling alert. That alone makes me suspicious.
I'm not exactly an expert on this, but reading it, I see several assumptions built in that seem at best infeasible. First, while they admit that they can do it on a LAN, they admit that it is much harder, and over a larger or busier network crossing multiple routers, this may not be feasible. Second, they seem to believe that "cloud computing" makes it more feasible because they believe the odds of being stacked on the same physical server as your target is good.
I'm not by any means saying that they haven't identified a weakness that needs to be fixed, but right now, I'd need more to accept their claim of how vulnerable everyone is to this.
Just for fun, I tried out that tool. I plugged in the symptoms I had when I cracked a rib. When I went to the doctor, the nurse diagnosed me before I even got to the exam room based just on watching me walk and hearing where the pain was. The software didn't even begin to ask the right questions, and assigned a 94% probability of something completely unrelated.
I also tried plugging in the symptoms I had a number of years back before I realized I had asthma. It's diagnosis was for several possibilities, none better than 24%.
However, a trained doctor, hearing me cough just once immediately recognized it as an asthma specific cough pattern.
So no, I wouldn't trust that tool over common sense, not even close.
I've never used an ATM for banking. My bank has branches in all the local grocery stores, and is open until at least six in the evening every week day. Saturday mornings, it is also open.
I've never had unwanted solicitations of services. The only time I was offered new services was when I asked questions indicating I was interested in such offers (like asking about online banking and they showed me information on online billpay).
I've never had to pay fees for my bank. They pay me for holding my money so that they can make loans to others. (Okay, so my interest rate is very low these days, it once was much higher).
I don't go into the physical bank even once a month, but when I do, they recognize me, and are genuinely friendly. If I have an odd question, they are more than happy to help, such as when my employer pushed me to a high deductible plan and I wanted to ask about my bank's HSA offering.
The idea of requiring me to only work with a computer is alien to me. I've done this with a few separate banks, and never had the problems others describe here.
Speaking as an outsider who has worked on PCI for the last several years.
There are a few ways this could happen. Sony could have focused on the sampled systems and forgotten another system. They may have been compliant at the time of the assessment and then allowed compliance to slip. There may have been a mitigating control on a non-compliance, accepted by the QSA, which turned out to not be as strong as believed. Or it may have been as strong as believed and caught the intrusion.
There is too much we don't know at this point. Now that it is confirmed that there was a chance of exposure of credit card numbers, the silence makes a lot of sense. There's a whole set of procedures to follow if you believe payment card numbers have been compromised.
What is likely to happen is if it is confirmed that credit card information was compromised, then there will be an investigation by the payment card industry into the source of the incident. This will then result likely in updated guidance for anyone who does credit card transactions that covers the area of the breach. Logging will be reemphasized to help detect attacks after the fact. (It always is).
And here it takes me nine minutes to get tea. One minute to find a mug and put water in it and start microwaving it. Two minutes to microwave, six minutes to steep. Enjoy hot. My wife's tea is faster (three minute brew). Brew time depends on the type of tea of course. If you really want ice tea, use twice as much tea for the volume, and then double the volume using ice (standard recipe I was taught from cook books and better tea shops).
I've seen unsweetened tea dispensers at plenty of restaurants in my area and where I grew up, and yes, I do consider anything in Texas the Deep South. It may not seem so politically, but the cuisine has distinctive southern aspects, such as beverage choices.
Most green teas I've had are just as bad as the lousy cheap tea available in restaurants here. Brewed at the wrong temperature, the wrong strength, the wrong time, using the cheapest possible tea fannings (dust). I've had good tea at restaurants, but it doesn't come from a soda style dispenser. When I go into a tea shop to sample their teas, I can tell when a tea has been sitting for too long by the flavor.
Actually, 0 C is just cool enough to stop wearing short pants and a t-shirt if you are from Minnesota.
Move out of the deep South. Unsweetened tea is common where I am, and also was common in the DC area where I grew up. It was crappy stuff, something I can't bring myself to drink because of how bad it tastes, but it is unsweetened tea. It took me years to learn how to brew tea and realize that the problem is restaurants are afraid of boiling water and thus brew black teas meant for seeping in water that is initially at a boiling temperature, at temperatures more suitable for delicate white or green teas, 140 F or less. To top it off, they don't even understand brew times up here.
Cheap amber oolong seems easy to find at those hole in the wall Chinese restaurants scattered everywhere, usually some form of teabag oolong brewed in a specialty tea brewing device that will keep a decent temperature for that tea, but don't try a black tea in those things. Those teas are never sweetened unless you add sugar at the table.
If you are looking for tea bags, most grocers I've seen have at least cheap, lousy teabags.
And yes, I buy real tea from a specialty store, but I do realize what is out there in tea, and in an emergency can make something I can at least stand to drink.
My observations match your references, everyone thinks they are eating the "right amount" to maintain their weight, no matter how much or little they eat. Very good kitchen scales (with .1 oz accuracy) are a must. As a bonus, this makes it easier to measure out the right amount of tea. And yes, my anecdote is that even people who eat too little to maintain their weight think they are eating the right amount.
This whole nonsense about sugar is just the latest extension of the craze diets that want to blame weight gain on something, anything other than eating more calories than used over time.
I suppose focusing on this is just the latest pendulum swing from the concern over children (and some adults) refusing to eat enough because they thought they would be too fat.
Publishers edit?
The word I am constantly being told is that your submission better be fully edited, publish ready before you submit.
Here's how we solved that problem. All access to root (except for documented emergencies) is done by sudo to a logging shell. The sudo invocation records who invoked that shell on what TTY. The logging shell, which logs off-host in real time, records the tty in addition to the timestamp and command (and euid). Then we can correlate from the sudo to identify "this is the shell history session for this user starting at this time."
My cfengine policy clears all those shell aliases and color codings on my RHEL boxes. Unfortunately, the HP-UX folks love their aliases. I can't count how often I watch someone type ll as an alias for ls -l and wonder why it doesn't work on a non-HP-UX box.
The -i flag of sudo isn't available on many of the versions of sudo I've used over the past many years. (No fair looking back when the -i flag was introduced). We used the -s flag instead.
Trust is a dirty word in audits. I don't care how much you think you can trust someone, without auditing, it's just guesswork. The PCI certification, 10.2.2 requires logging actions taken with administrative privilege. That means not just the command to take a root shell, but what the user ran beneath that.
It's very common for sudo to log to syslog. It's also very common for syslog to log in real time off-host. The user may break the logging trail, but they won't hide the command they ran to break the logging trail.
On my box, /bin -> /usr/bin