The people involved did a despicable thing. But I can't see how it's any more illegal than someone shouting "Jump!" at someone on a roof top when emergency services are trying to talk them down.
The difference is simple. It's in writing, here. There's money to be made.
I don't quite follow your point...are you saying that Reddit's business model encourages people to egg others on to cause suicide, because it was in writing? I don't follow how that's true at all. The people egging him on were commenters, who don't get paid to comment. And if you read the actual comment thread, you'll see that there were quite a few people trying to talk him out of it as well; did they all cause Reddit to lose money, or have to pay to post their comments?
If you want to point fingers at every situation where there's some organization with a profit-loss statement that is in any way tangentially involved in someone doing something wrong, you're going to need a HELL of a lot of fingers. And it doesn't mean that profit was ever the motive in the wrongdoing. Gah, why don't you complain about the profit motive of the company that made the sidewalk he landed on, while you're at it? Good thing there's no money in gravity...
You obviously don't know much about SCADA systems. They are proprietary, top to bottom. And there are reasons for this that do make sense.
First of all, let's look at the whole picture of a SCADA implementation...in this example, I'll talk about the systems that control and analyze the burn inside a coal-fired power generation facility that uses coal to heat water into steam which then drives a turbine; this is the kind of power plant that produces most of the power in our country. (I'm in the United States, for context there.) The systems are analagous to the ECU of a car with a fuel-injection engine, both controlling the delivery of fuel and air while monitoring the effects of those controls in the context of the demands being placed upon the boiler. Just as with a car engine, there is lag in making changes to the burn, just as an engine has delay when you step on the throttle.
There are many devices involved...gas sensors, temperature sensors, lasers...and all of them are purpose-built by the company that makes the control system; they are proprietary. The protocols that are spoken between devices are usually open, like DNP3 or modbus, but the data schemas that are used are also proprietary (most ICS protocols are pretty soft, working more like a layer 6 protocol than a layer 7). The logic that drives decisions, reporting, and the translation of human interaction into discrete behavior by control devices? Also proprietary. The control systems are built by the same company to work end-to-end on that specific type, size and model of boiler, and the whole thing is tested as a unit. For the most part, the notion of modularity...the way that you could replace a Cisco firewall with an equivalent Juniper firewall, or replace an EMC SAN with a NetApp SAN...does not exist in any way whatsoever. (It does in small ways, but even then most manufacturers will refuse to support the system if you so much as change the IOS image on a Cisco switch without it having been tested first, which takes about 6 months for a full facility and requires that it be offline the whole time.)
The complexity of these environments...and the ramifications of improper behavior by any one component...cannot be overstated. So, it's essential from a legal standpoint to have entities backing the pre-manufactured components who can be held accountable should it be necessary. I know, you can't sue Microsoft for software bugs, but you can't look at their behavior over the past 15 years and tell me that there wasn't an effective motivation to improve security. They've dramatically improved the security quality of Windows, while rolling out and evolving a patching system that is now the gold standard for software companies. They have something to lose from producing an unreliable product, even if that loss does not come in the form of a lawsuit. And after seeing what Oracle has done to mySQL and Java, it's not hard to see the potential for disaster if you rely on an open-source project that may have to fork because their patron got acquired, as well. An even scarier possibility is what Tenable did with Nessus when they forked and closed the source, ending support for the older OSS version.
One more thing...this isn't a website we're talking about. It's a power plant. When things go wrong in these environments, it isn't just embarassing. People often die. At one plant I've done work at, a mistake caused a ~300 KV transformer to detonate. Oversimplifying the situation, the power ended up flowing the wrong way, and the transformer's cooling spaces (filled with oil) exploded in a BLEVE, showering the nearby parking lot with flaming oil. It was a Michael Bay-like situation; I saw the pictures that were taken while the fires were still burning. A mistake involving the boiler can cause the flame to collapse resulting what they call a "beer can," when the fire suddenly goes out and the inside of the boiler cools so rapidly (in a matter of seconds, or less) that it crushes itself. This is not a small thing...the walls
Actually, a lot of people install Backtrack and run it as the resident install on their hard drives. Not what I would do, but then, not everyone is able to build their own system for pen-testing in the first place.
Okay, for one thing, I'm trying to figure out why you're worried about "safe". Your intent is to watch Netflix and Hulu with the VPN service? What are you worried about? Yes, I know...both take credit cards...but they do so over SSL.
Your biggest problem will be throughput, and potentially latency. A VPN does not help with network performance, and neither does adding more hops to the route that the traffic will have to follow...especially when the server with be US-based and you'll be on the other side of the pond in Europe. So whatever service you do look at, make sure that they will be able to keep the data flowing at the bandwidth rates you need, and without causing problems from latency. And remember...latency and bandwidth are kind of related, but not the same thing. You can have high latency on a huge pipe, and low latency on a skinny one.
It doesn't help against DDoS attacks. Not even remotely, not even a little bit. To put the advice to a metaphor, a DDoS attack is where there are so many people loitering in the front lobby of a business that people can't even get into the front door of a building. Using a different web server is like having a receptionist who speaks faster; it doesn't address the nature of the attack in the slightest way possible. These attacks are either driven by saturation of network links or by leveraging vulnerabilities in underlying database-driven applications (hint: a little-known SQL command called WAITFOR is often to blame); using nginx won't help in the slightest bit.
Christ...these attacks are over a decade old; read up or be quiet.
The people's social security numbers were compromised...should we say that Social Security got hacked? Hey, when Global Payments got breached, does that mean that Visa and MasterCard both got hacked? No. Because when you refer to just "Visa," you refer to the organization that underpins Visa cards...and saying that they got hacked refers to an organization that is entirely different and separate. The fact that some of the people who got hacked were on Medicaid (the others were on CHIP) does not mean that the Medicaid organization got hacked.
Utah's state department of health is NOT Medicaid, nor is it a subset of the 'program' that is called Medicaid. Their procurement is different, their mandate is different and they can only follow the standards and policies put down to them by the Medicaid program (which is federal in nature, not run by Utah), as opposed to determining or setting them. These are just a few of the "subtle hints" that the two organizations are entirely separate and distinct from each other...and that, relevant to my point, their IT security measures are controlled entirely differently from each other (Utah's program isn't even subject to FISMA), and thus hacking one is not the same as hacking the other.
Okay, Slashdot seems to be getting worse and worse about distorting things in the titles of the topics. "Medicaid Hacked" is NOT what happened here. Not even close. And when the first line of the topic's body is "The Utah Department of Health has been hacked," then you can't even excuse the poster as having been a little confused; it's flagrant tabloid-like sensationalism. Cut it out, already.
Obviously, you can't open source your product and make money off sales of the product; the two are by definition incompatible. The way that open-source based businesses make their money is on services...integration/implementation, support, that kind of thing. But these require a critical mass to exist; if there isn't a good-sized install base, there can be no demand for services. And if you take the route of putting out a great product in open source and then forking/commercializing it (like Tenable did with Nessus, for example) then you will likely piss off a lot of people, and fail entirely if your product isn't totally bananas-great. (Admittedly, Nessus is that great, which is why people still use it.) So, honestly, you have to decide between being a viable start-up company with a product or being an open-source project that may, if you're lucky, eventually result in a need for services that you can then provide a few years from now. The two do not coincide here...and just using some kind of business model will not alter the way that the laws of supply and demand interact.
A few years we were in the same position as you are. We wanted to open source some of our technology and software but were trying to figure out how to make it work. Eventually we decided to offer both proprietary version of our software, and open source one. They are fairly identical and we offer support services for both.
The trick is, to ensure that we would convert the open source users to paying ones, we made most of the software features to do the heavy work on our servers, and then would strip the code altogether from the open source version. If users wanted to use the program they would for all practicality need to buy an yearly support contract from us, which included access to the servers hosting the code. On top of that we introduced various bugs and weird failures to the open source version, which would mean that the open source users would call our premium priced support telephone number. We needed to fine tune this over the year a bit , as we didn't introduce enough bugs in the beginning. But later we would start getting lots of support calls for bugs and it made a good amount of money.
This also made quite many sales of the proprietary version, so in overall it worked quite well. You might want to try something similar.
Ohhhh...you work for Tenable, don't you? Or are you Oracle's new head of product development?
The technologies being developed by the Navy also have another use: the current battle plan for the Iranian Navy, should they decide to harass shipping traffic (again) or try to close the Strait of Hormuz would be to use lots of small boats, much as the pirates do. But unlike the pirates, they would tend to be more destructive instead of trying to board the ships. Being able to detect those boats from afar, recognize them as a threat and then destroy/deter them from a standoff distance is the key to maintaining open traffic there, and incredibly difficult to do.
The title of the slashdot posting missed the point entirely. The point is not to reward failure, but instead to accept it. Failure is an inherent part of moving forward, especially when it comes to innovation. You can't honestly expect every attempt to have a 100% success rate, and if you restrict all new efforts to those which you believe have almost no chance of failing...well, you won't be making many efforts at all. Does anyone remember how many people were skeptical about the first iPad, groaning about the price, about how it wasn't enough to be a computer (which you could also buy at the same cost) but wasn't able to serve as a phone? A failure-intolerant environment would have listened to those concerns, and the iPad never would have launched. And what a mistake THAT would have been..
Your provider has de-facto admitted that they messed up. These things happen.
Um...not really, not if the hosting provider is doing things the right way. And that's the problem. I will elaborate...
The only question is whether they would truly respond in a professional manner. If they do, and they agree to the following, do the following, and move on. Contact them, and request them to:
* Provision a new virtual host for you.
This will not address the fact that there's clearly an issue with the underlying processes and procedures that should have prevented this in the first place. This was a *process* breakdown, not a question of architectural segregation. A new virtual host, (improperly) protected by the same procedural controls, is no more secure.
* You will copy all your existing data into your new virtual host, using your own copies of whatever you use the host for. You do have your own copies of everything, and you don't trust the host with the entirety of your data, right?
See above, about "process breakdown."
* For convenience, I think it's ok to copy some data directly from your compromised host, provided that you're comfortable with whatever verification steps you deem are necessary to certify that it hasn't been tampered with. Data, no code.
See above, again, about "process breakdown."
* When your migration is complete, your provider will swap in your replacement virtual host in place of the compromised one, which they'll decomission.
See above, about "process breakdown." I keep saying it because none of these points addresses that problem, which is the root cause of this and the source of future risk of the same nature.
Of course, for the duration of your migration, your host will not charge you for the second virtual host. You might consider negotiation with your host for an additional discount, as compensation for the work you have to do as a result of their security breach. I think that free hosting for however long it takes you to migrate, that is, no charge for the new virtual host, and billing suspended for your compromised host, would be fair. If that's the two weeks they're already willing to give you, then that's that.
The problem is that something non-technical failed here. It wasn't a buffer overflow, it wasn't a bad firewall rule, it wasn't a zero-day vulnerability. The title of the Slashdot topic is the key: "My Host Gave a Stranger Access". Unless that Host changes what they did wrong the first time, it doesn't matter which server within their control you reside on, or if you're supposed to be there all by yourself. It comes down to if they can demonstrate to you, transparently, what they did wrong and what they have done to fix it. It sounds like there's been a lack of transparency as to the breach, at least at first; that is not a good sign. Good luck, but you may have to take your business elsewhere.
No administrative commands? You mean "SELECT", as is used in most injection attacks? THAT administrative command?
Look, there's a reason that everyone in the application security space says to whitelist when you sanitize your inputs, rather than blacklist. There are too many ways to slip things past a blacklist which are often defined by the nature of the application rather than the COTS and OSS software used to architect it. No library call is going to effectively stop "bad stuff." If you have authentication credentials in your DB (hint: you do) and I can inject SQL into the query that is passed to it, I can get those credentials, without using any SQL calls that aren't used in a very innocuous and mundane request for data. And most of the time, I can use those credentials directly, in the same manner as the person who is intended to use them. And this is just one example...one single example...of one kind of injection attack. (It's also one of the most common ones.)
So, I went to the site (be patient; it'll respond eventually) and looked at the section called "GreenSQL Performance Test." I found some fairly interesting benchmarks, which looked good...until I looked at the details. For one thing, they disabled logging...yes, on a security component, they set loglevel to 0. They also disabled the "risk calculation" capability, which is one of their selling (sourcing?) points. I have to wonder what the performance would be like with loglevel set a bit higher, so that you would actually get notice of any failed SQL-based attacks; if the SQL calls are homogenous enough, you can get by without the risk calculation feature by doing a proper ruleset. But no logging? Oy...I can't imagine that would fly in most places where they would be implementing this kind of technology. It certainly fails PCI compliance, that's for sure.
How standardized is robotic hardware? With the LAMP stack, you're creating an environment with integrated components for OS, database, web services and application services so that you can build what you need from end-to-end. But it seems to me that with robotics, you have one more step to go: the kinetic/physical representation of things. Are there standards for the description of spatial relationships, feedback from sensors and movement directives? I'm not challenging the idea; I think it's great. But I'm curious about this one aspect of it, since I know very little about the robotics world and think that many of the people who will comment on this are in the same boat. (Thus, some clarity on this may improve the quality of comments...somewhat.)
Google is in the midst of an effort to inform people about privacy. Not by saying "hey, listen up" and then dictating information to them, but by doing everything they can to get people to look at Google's own use of data and the rules they set for themselves around privacy. All those times when they kept telling us that their privacy policy had changed? Yeah, that's a part of it. Also, for those in urban envionments who take the L, T, Subway, Metro, whatever...you've probably seen the ads explaining at a high level how they use the data they collect to personalize search results. Now this is the next step: giving them the opportunity to see how analytics work in a way that is relevant to their understanding, and to their own lives.
The big problem with privacy isn't that people aren't getting it...it's that people aren't demanding it. But until they know what privacy really is (no, it's not security) and how it works, that won't change. Until they actually pay attention to what is being done with their own information, how can we expect an uproar over the abuse of it? That's what Google is up to now, and I commend them for it. They are playing a VERY forward-thinking game, and are truly acting in the best interests of the common good.
A tool equipped with a tiny video camera, a thermometer, a dosimeter and a water gauge was used to assess damage inside Lindsay Lohan, and came to the exact same conclusions before the tip of the tool corroded.
What do you define as "specialized hardware," exactly? The iPhone doesn't exactly keep the PIN on a USB drive...by definition it is specialized hardware, in and of itself. And what you describe as what should happen if the PIN is incorrectly entered enough times is already a native iPhone feature.
And of course the OS has to have access to your data without the PIN; how is it going to tell you that you got a new text, email or phone call? How will it tell you the name of who is calling based on their phone number? How will it let you know that you have that meeting coming up in 15 minutes, like you want it to do? And most of all...how will it know that the PIN you gave it is the right one? There are ways to make devices more secure against side-channel attacks, but what you're describing is infeasible, impractical and pretty much impossible anyways.
It doesn't matter where you keep the PIN, hardware-wise, in this case since the problem is software related. And you don't encrypt anything with a PIN; a PIN that any human could ever remember has WAY too short a length and too little entropy to be useful. The PIN is nothing more than an authentication factor.
And if you don't know of any phones that implement a really good security scheme, it's either because you don't know what a Blackberry is, or because you don't know how to build security around a mobile device. I'm betting on the latter...
There goes my business plan to launch a bold new competitor to Facebook that, in my opinion, better captures the spirit of social media today. I was going to call it "Assbook".
There's a larger game afoot here than just price. This is about what happens in the long-term when a country unfairly supports a domestic industry and artificially lowers the cost of that industry's products on the marketplace. What results from this is the failure of producers of that good in other countries, which in turn results in a monopoly, or at the very least, market share dominance. Then, the prices can go back up, leaving other countries with less competition and a strategic disadvantage. In this case, that disadvantage also includes an energy source, so there's a double-risk.
And yes, I know...they can always just start up new companies, right? Wrong...it's not that easy. Because in the meanwhile, the surviving companies have been able to invest in R&D, and further lower costs, improve manufacturing processes, and innovate, all of which raise the barrier to entry in the market. And even if a company elsewhere comes onto the market and starts competing effectively...China would only have to start subsidizing their own industry again to put them at a disadvantage, and the cycle repeats itself.
You might want to click on the link. Granted, the BBC is clearly a fly-by-night news operation with only a few reporters, no reputation to speak of and almost no history in journalism, but yeah...it's they who broke the story, not samzenpus.
The focus is realistic (aiming on the US specifically, which is where most bot activity originates anyways) and measured. They don't prescribe specific draconian regimens, but instead offer approaches and support the use of as many as are feasible. But most of all it takes the approach of "this is good for all of us," and ensure that the measures described fit that as well. This is the kind of approach that works well for industry by providing guidance, goals and options so that business can tailor their methods to what works well within their own operational constraints.
I think you mean Mudge. Mudge is the L0pht Heavy Industries alumnus who is at DARPA.
Also, the reason why 'insider threat' = whistleblowers in this scenario is because technical controls cannot interpret or extrapolate intent. They can't tell the reason why information is being extracted from a secure environment, only that it is. The lack of differentiation is not some nefarious scheme to catch well-meaning whistleblowers along with spies, just a shortcoming of technology. A hammer doesn't know whether or not it's being used for good or bad either.
Slashdot Mirror
The people involved did a despicable thing. But I can't see how it's any more illegal than someone shouting "Jump!" at someone on a roof top when emergency services are trying to talk them down.
The difference is simple. It's in writing, here. There's money to be made.
I don't quite follow your point...are you saying that Reddit's business model encourages people to egg others on to cause suicide, because it was in writing? I don't follow how that's true at all. The people egging him on were commenters, who don't get paid to comment. And if you read the actual comment thread, you'll see that there were quite a few people trying to talk him out of it as well; did they all cause Reddit to lose money, or have to pay to post their comments?
If you want to point fingers at every situation where there's some organization with a profit-loss statement that is in any way tangentially involved in someone doing something wrong, you're going to need a HELL of a lot of fingers. And it doesn't mean that profit was ever the motive in the wrongdoing. Gah, why don't you complain about the profit motive of the company that made the sidewalk he landed on, while you're at it? Good thing there's no money in gravity...
You obviously don't know much about SCADA systems. They are proprietary, top to bottom. And there are reasons for this that do make sense.
First of all, let's look at the whole picture of a SCADA implementation...in this example, I'll talk about the systems that control and analyze the burn inside a coal-fired power generation facility that uses coal to heat water into steam which then drives a turbine; this is the kind of power plant that produces most of the power in our country. (I'm in the United States, for context there.) The systems are analagous to the ECU of a car with a fuel-injection engine, both controlling the delivery of fuel and air while monitoring the effects of those controls in the context of the demands being placed upon the boiler. Just as with a car engine, there is lag in making changes to the burn, just as an engine has delay when you step on the throttle.
There are many devices involved...gas sensors, temperature sensors, lasers...and all of them are purpose-built by the company that makes the control system; they are proprietary. The protocols that are spoken between devices are usually open, like DNP3 or modbus, but the data schemas that are used are also proprietary (most ICS protocols are pretty soft, working more like a layer 6 protocol than a layer 7). The logic that drives decisions, reporting, and the translation of human interaction into discrete behavior by control devices? Also proprietary. The control systems are built by the same company to work end-to-end on that specific type, size and model of boiler, and the whole thing is tested as a unit. For the most part, the notion of modularity...the way that you could replace a Cisco firewall with an equivalent Juniper firewall, or replace an EMC SAN with a NetApp SAN...does not exist in any way whatsoever. (It does in small ways, but even then most manufacturers will refuse to support the system if you so much as change the IOS image on a Cisco switch without it having been tested first, which takes about 6 months for a full facility and requires that it be offline the whole time.)
The complexity of these environments...and the ramifications of improper behavior by any one component...cannot be overstated. So, it's essential from a legal standpoint to have entities backing the pre-manufactured components who can be held accountable should it be necessary. I know, you can't sue Microsoft for software bugs, but you can't look at their behavior over the past 15 years and tell me that there wasn't an effective motivation to improve security. They've dramatically improved the security quality of Windows, while rolling out and evolving a patching system that is now the gold standard for software companies. They have something to lose from producing an unreliable product, even if that loss does not come in the form of a lawsuit. And after seeing what Oracle has done to mySQL and Java, it's not hard to see the potential for disaster if you rely on an open-source project that may have to fork because their patron got acquired, as well. An even scarier possibility is what Tenable did with Nessus when they forked and closed the source, ending support for the older OSS version.
One more thing...this isn't a website we're talking about. It's a power plant. When things go wrong in these environments, it isn't just embarassing. People often die. At one plant I've done work at, a mistake caused a ~300 KV transformer to detonate. Oversimplifying the situation, the power ended up flowing the wrong way, and the transformer's cooling spaces (filled with oil) exploded in a BLEVE, showering the nearby parking lot with flaming oil. It was a Michael Bay-like situation; I saw the pictures that were taken while the fires were still burning. A mistake involving the boiler can cause the flame to collapse resulting what they call a "beer can," when the fire suddenly goes out and the inside of the boiler cools so rapidly (in a matter of seconds, or less) that it crushes itself. This is not a small thing...the walls
Actually, a lot of people install Backtrack and run it as the resident install on their hard drives. Not what I would do, but then, not everyone is able to build their own system for pen-testing in the first place.
Okay, for one thing, I'm trying to figure out why you're worried about "safe". Your intent is to watch Netflix and Hulu with the VPN service? What are you worried about? Yes, I know...both take credit cards...but they do so over SSL.
Your biggest problem will be throughput, and potentially latency. A VPN does not help with network performance, and neither does adding more hops to the route that the traffic will have to follow...especially when the server with be US-based and you'll be on the other side of the pond in Europe. So whatever service you do look at, make sure that they will be able to keep the data flowing at the bandwidth rates you need, and without causing problems from latency. And remember...latency and bandwidth are kind of related, but not the same thing. You can have high latency on a huge pipe, and low latency on a skinny one.
It doesn't help against DDoS attacks. Not even remotely, not even a little bit. To put the advice to a metaphor, a DDoS attack is where there are so many people loitering in the front lobby of a business that people can't even get into the front door of a building. Using a different web server is like having a receptionist who speaks faster; it doesn't address the nature of the attack in the slightest way possible. These attacks are either driven by saturation of network links or by leveraging vulnerabilities in underlying database-driven applications (hint: a little-known SQL command called WAITFOR is often to blame); using nginx won't help in the slightest bit.
Christ...these attacks are over a decade old; read up or be quiet.
The people's social security numbers were compromised...should we say that Social Security got hacked? Hey, when Global Payments got breached, does that mean that Visa and MasterCard both got hacked? No. Because when you refer to just "Visa," you refer to the organization that underpins Visa cards...and saying that they got hacked refers to an organization that is entirely different and separate. The fact that some of the people who got hacked were on Medicaid (the others were on CHIP) does not mean that the Medicaid organization got hacked.
Utah's state department of health is NOT Medicaid, nor is it a subset of the 'program' that is called Medicaid. Their procurement is different, their mandate is different and they can only follow the standards and policies put down to them by the Medicaid program (which is federal in nature, not run by Utah), as opposed to determining or setting them. These are just a few of the "subtle hints" that the two organizations are entirely separate and distinct from each other...and that, relevant to my point, their IT security measures are controlled entirely differently from each other (Utah's program isn't even subject to FISMA), and thus hacking one is not the same as hacking the other.
Okay, Slashdot seems to be getting worse and worse about distorting things in the titles of the topics. "Medicaid Hacked" is NOT what happened here. Not even close. And when the first line of the topic's body is "The Utah Department of Health has been hacked," then you can't even excuse the poster as having been a little confused; it's flagrant tabloid-like sensationalism. Cut it out, already.
Obviously, you can't open source your product and make money off sales of the product; the two are by definition incompatible. The way that open-source based businesses make their money is on services...integration/implementation, support, that kind of thing. But these require a critical mass to exist; if there isn't a good-sized install base, there can be no demand for services. And if you take the route of putting out a great product in open source and then forking/commercializing it (like Tenable did with Nessus, for example) then you will likely piss off a lot of people, and fail entirely if your product isn't totally bananas-great. (Admittedly, Nessus is that great, which is why people still use it.) So, honestly, you have to decide between being a viable start-up company with a product or being an open-source project that may, if you're lucky, eventually result in a need for services that you can then provide a few years from now. The two do not coincide here...and just using some kind of business model will not alter the way that the laws of supply and demand interact.
A few years we were in the same position as you are. We wanted to open source some of our technology and software but were trying to figure out how to make it work. Eventually we decided to offer both proprietary version of our software, and open source one. They are fairly identical and we offer support services for both.
The trick is, to ensure that we would convert the open source users to paying ones, we made most of the software features to do the heavy work on our servers, and then would strip the code altogether from the open source version. If users wanted to use the program they would for all practicality need to buy an yearly support contract from us, which included access to the servers hosting the code. On top of that we introduced various bugs and weird failures to the open source version, which would mean that the open source users would call our premium priced support telephone number. We needed to fine tune this over the year a bit , as we didn't introduce enough bugs in the beginning. But later we would start getting lots of support calls for bugs and it made a good amount of money.
This also made quite many sales of the proprietary version, so in overall it worked quite well. You might want to try something similar.
Ohhhh...you work for Tenable, don't you? Or are you Oracle's new head of product development?
The technologies being developed by the Navy also have another use: the current battle plan for the Iranian Navy, should they decide to harass shipping traffic (again) or try to close the Strait of Hormuz would be to use lots of small boats, much as the pirates do. But unlike the pirates, they would tend to be more destructive instead of trying to board the ships. Being able to detect those boats from afar, recognize them as a threat and then destroy/deter them from a standoff distance is the key to maintaining open traffic there, and incredibly difficult to do.
The title of the slashdot posting missed the point entirely. The point is not to reward failure, but instead to accept it. Failure is an inherent part of moving forward, especially when it comes to innovation. You can't honestly expect every attempt to have a 100% success rate, and if you restrict all new efforts to those which you believe have almost no chance of failing...well, you won't be making many efforts at all. Does anyone remember how many people were skeptical about the first iPad, groaning about the price, about how it wasn't enough to be a computer (which you could also buy at the same cost) but wasn't able to serve as a phone? A failure-intolerant environment would have listened to those concerns, and the iPad never would have launched. And what a mistake THAT would have been..
Your provider has de-facto admitted that they messed up. These things happen.
Um...not really, not if the hosting provider is doing things the right way. And that's the problem. I will elaborate...
The only question is whether they would truly respond in a professional manner. If they do, and they agree to the following, do the following, and move on. Contact them, and request them to:
* Provision a new virtual host for you.
This will not address the fact that there's clearly an issue with the underlying processes and procedures that should have prevented this in the first place. This was a *process* breakdown, not a question of architectural segregation. A new virtual host, (improperly) protected by the same procedural controls, is no more secure.
* You will copy all your existing data into your new virtual host, using your own copies of whatever you use the host for. You do have your own copies of everything, and you don't trust the host with the entirety of your data, right?
See above, about "process breakdown."
* For convenience, I think it's ok to copy some data directly from your compromised host, provided that you're comfortable with whatever verification steps you deem are necessary to certify that it hasn't been tampered with. Data, no code.
See above, again, about "process breakdown."
* When your migration is complete, your provider will swap in your replacement virtual host in place of the compromised one, which they'll decomission.
See above, about "process breakdown." I keep saying it because none of these points addresses that problem, which is the root cause of this and the source of future risk of the same nature.
Of course, for the duration of your migration, your host will not charge you for the second virtual host. You might consider negotiation with your host for an additional discount, as compensation for the work you have to do as a result of their security breach. I think that free hosting for however long it takes you to migrate, that is, no charge for the new virtual host, and billing suspended for your compromised host, would be fair. If that's the two weeks they're already willing to give you, then that's that.
The problem is that something non-technical failed here. It wasn't a buffer overflow, it wasn't a bad firewall rule, it wasn't a zero-day vulnerability. The title of the Slashdot topic is the key: "My Host Gave a Stranger Access". Unless that Host changes what they did wrong the first time, it doesn't matter which server within their control you reside on, or if you're supposed to be there all by yourself. It comes down to if they can demonstrate to you, transparently, what they did wrong and what they have done to fix it. It sounds like there's been a lack of transparency as to the breach, at least at first; that is not a good sign. Good luck, but you may have to take your business elsewhere.
No administrative commands? You mean "SELECT", as is used in most injection attacks? THAT administrative command?
Look, there's a reason that everyone in the application security space says to whitelist when you sanitize your inputs, rather than blacklist. There are too many ways to slip things past a blacklist which are often defined by the nature of the application rather than the COTS and OSS software used to architect it. No library call is going to effectively stop "bad stuff." If you have authentication credentials in your DB (hint: you do) and I can inject SQL into the query that is passed to it, I can get those credentials, without using any SQL calls that aren't used in a very innocuous and mundane request for data. And most of the time, I can use those credentials directly, in the same manner as the person who is intended to use them. And this is just one example...one single example...of one kind of injection attack. (It's also one of the most common ones.)
So, I went to the site (be patient; it'll respond eventually) and looked at the section called "GreenSQL Performance Test." I found some fairly interesting benchmarks, which looked good...until I looked at the details. For one thing, they disabled logging...yes, on a security component, they set loglevel to 0. They also disabled the "risk calculation" capability, which is one of their selling (sourcing?) points. I have to wonder what the performance would be like with loglevel set a bit higher, so that you would actually get notice of any failed SQL-based attacks; if the SQL calls are homogenous enough, you can get by without the risk calculation feature by doing a proper ruleset. But no logging? Oy...I can't imagine that would fly in most places where they would be implementing this kind of technology. It certainly fails PCI compliance, that's for sure.
How standardized is robotic hardware? With the LAMP stack, you're creating an environment with integrated components for OS, database, web services and application services so that you can build what you need from end-to-end. But it seems to me that with robotics, you have one more step to go: the kinetic/physical representation of things. Are there standards for the description of spatial relationships, feedback from sensors and movement directives? I'm not challenging the idea; I think it's great. But I'm curious about this one aspect of it, since I know very little about the robotics world and think that many of the people who will comment on this are in the same boat. (Thus, some clarity on this may improve the quality of comments...somewhat.)
Google is in the midst of an effort to inform people about privacy. Not by saying "hey, listen up" and then dictating information to them, but by doing everything they can to get people to look at Google's own use of data and the rules they set for themselves around privacy. All those times when they kept telling us that their privacy policy had changed? Yeah, that's a part of it. Also, for those in urban envionments who take the L, T, Subway, Metro, whatever...you've probably seen the ads explaining at a high level how they use the data they collect to personalize search results. Now this is the next step: giving them the opportunity to see how analytics work in a way that is relevant to their understanding, and to their own lives.
The big problem with privacy isn't that people aren't getting it...it's that people aren't demanding it. But until they know what privacy really is (no, it's not security) and how it works, that won't change. Until they actually pay attention to what is being done with their own information, how can we expect an uproar over the abuse of it? That's what Google is up to now, and I commend them for it. They are playing a VERY forward-thinking game, and are truly acting in the best interests of the common good.
A tool equipped with a tiny video camera, a thermometer, a dosimeter and a water gauge was used to assess damage inside Lindsay Lohan, and came to the exact same conclusions before the tip of the tool corroded.
What do you define as "specialized hardware," exactly? The iPhone doesn't exactly keep the PIN on a USB drive...by definition it is specialized hardware, in and of itself. And what you describe as what should happen if the PIN is incorrectly entered enough times is already a native iPhone feature.
And of course the OS has to have access to your data without the PIN; how is it going to tell you that you got a new text, email or phone call? How will it tell you the name of who is calling based on their phone number? How will it let you know that you have that meeting coming up in 15 minutes, like you want it to do? And most of all...how will it know that the PIN you gave it is the right one? There are ways to make devices more secure against side-channel attacks, but what you're describing is infeasible, impractical and pretty much impossible anyways.
It doesn't matter where you keep the PIN, hardware-wise, in this case since the problem is software related. And you don't encrypt anything with a PIN; a PIN that any human could ever remember has WAY too short a length and too little entropy to be useful. The PIN is nothing more than an authentication factor.
And if you don't know of any phones that implement a really good security scheme, it's either because you don't know what a Blackberry is, or because you don't know how to build security around a mobile device. I'm betting on the latter...
There goes my business plan to launch a bold new competitor to Facebook that, in my opinion, better captures the spirit of social media today. I was going to call it "Assbook".
There's a larger game afoot here than just price. This is about what happens in the long-term when a country unfairly supports a domestic industry and artificially lowers the cost of that industry's products on the marketplace. What results from this is the failure of producers of that good in other countries, which in turn results in a monopoly, or at the very least, market share dominance. Then, the prices can go back up, leaving other countries with less competition and a strategic disadvantage. In this case, that disadvantage also includes an energy source, so there's a double-risk.
And yes, I know...they can always just start up new companies, right? Wrong...it's not that easy. Because in the meanwhile, the surviving companies have been able to invest in R&D, and further lower costs, improve manufacturing processes, and innovate, all of which raise the barrier to entry in the market. And even if a company elsewhere comes onto the market and starts competing effectively...China would only have to start subsidizing their own industry again to put them at a disadvantage, and the cycle repeats itself.
You might want to click on the link. Granted, the BBC is clearly a fly-by-night news operation with only a few reporters, no reputation to speak of and almost no history in journalism, but yeah...it's they who broke the story, not samzenpus.
Wait...you mean, Kazakhstan DOESN'T have the region's cleanest prostitutes? Uh oh...(makes doctor's appointment)
The focus is realistic (aiming on the US specifically, which is where most bot activity originates anyways) and measured. They don't prescribe specific draconian regimens, but instead offer approaches and support the use of as many as are feasible. But most of all it takes the approach of "this is good for all of us," and ensure that the measures described fit that as well. This is the kind of approach that works well for industry by providing guidance, goals and options so that business can tailor their methods to what works well within their own operational constraints.
"Julie Amero"
I think you mean Mudge. Mudge is the L0pht Heavy Industries alumnus who is at DARPA.
Also, the reason why 'insider threat' = whistleblowers in this scenario is because technical controls cannot interpret or extrapolate intent. They can't tell the reason why information is being extracted from a secure environment, only that it is. The lack of differentiation is not some nefarious scheme to catch well-meaning whistleblowers along with spies, just a shortcoming of technology. A hammer doesn't know whether or not it's being used for good or bad either.