35 posts • joined 7 Jun 2017
Re: Arm Laser Turrets!
> "...And if you don't use a laser strong enough to actually damage the camera, there is nothing anybody could sue you about; AFAIK there is no law against shining lasers on drones hovering over your garden..."
With people's luck today, the dazzler laser would have enough range to point at a passing jumbo jet - pretty sure that's illegal. Most people who aren't trained to shoot guns around people aren't aware of the concept of ballistic backdrop... ;-)
If your house has SmartGlass on it, why not take the time to actually detect the drone, and then automatically opaque the windows?
Seems like a few upwards facing cameras with very wide angle lenses and an electronic iris, should be able to detect a drone or birds - and classify if the object is loitering or flying past for simple classification. Then piggy back that with some SDR radio direction finding (https://www.youtube.com/watch?v=8Wzb1mgZ0EE), and you should be able to further pick out if that "bird" is emitting radio waves...
> How many people are actually monitoring extra wifi streams anyway?
Depends on the person and their circumstances. I live in an apartment over a coffee shop and a restaurant. After my wireless internet slowed down, I started looking at my AP's access table - I found a few devices that didn't belong, and I had WPA2 (but no RADIUS or equivalent). So I added two more commercial APs, wrote a tool to take the RSSI from each antenna and triangulate the location of the radio into a 3D volume (in addition to the other network hardening I did). I found that the tables outside the coffee shop were getting used by a local geek to try his circumvention tools. I retooled my network routing/partitioning to isolate him, making him think he was getting on "free" (stolen) WiFi as usual then redirected every outgoing request to a local copy of: https://www.youtube.com/watch?v=dQw4w9WgXcQ
That slowed him down for a day or two, so after that I, had my wife record "HEY!! ARE YOU WATCHING PORN?!?!?!" and I play that audio file in embedded in my warning page now for every client that shows up outside my apartment volume. Haven't seen that 90's silver VW Golf or the heavy-set unshaven guy who drove it and sat outside the coffee shop with his laptop in a while now...
But, I did recently see in the logs a WiFi AP appear airborne across the street from me, at the city park - where it's illegal by city ordinance to fly a drone...
Point is, just because YOU aren't watching the extra streams, don't assume nobody else in the world is or that there isn't a good reason in general for people to be doing that at all.
Meltdown is not comprehensively protcted agaist.
@El Reg "Meltdown = job done" is a BS thought right now. Even if Intel managed to develop a micro-code workaround to the design flaw, at boot this requires a BIOS flash to achieve. Good luck finding a vendor who is going to dust off the tempermental leased Intel development platforms to give that a try for every motherboard SKU they've released in the last 10 years... from my experience, Intel tells vendors to sod off after the first year of release, especially if there's no new money in it for them.
Then there is the issue of Specter fixes, pushing the fix burden on software people is a fantastic way to get software people to hate your living guts. At the OS level the vendors are probably finding out right now that even they didn't fully understand all of the use-cases, and that's probably where we will get the drawn out reporting of major slow downs. It'll take a while for the individual application software vendors to touch their code again to optimize around the new kernel controls, so this story will linger for 5+ year IMHO.
I'd wait the cast >final< judgement on the impact of the Meltdown/Specter bugs until the second fiscal quarter well after Jan 1 2018. By then you should be able to see Intel making stock charges to hold reserves for lawsuit settlements, machine performance contract breaches at the larger datacenters, and hits from the various computer manufacturers.
Re: timing attacks
Reducing timer accuracy will mean you can only fire events on more coarse intervals, which would necessitate a slow down (missing an event at a near time slot would mean you now wait much longer for the next) - and let's be frank, while the "impact" may not be felt on the local client machine's CPU, most of us home bodies are touching something on a VM or a database in a datacenter over a network, so IMHO we will actually feel it at the screen. Even if just subtly. I believe yes, the datacenter people are going to spend most of their time talking up how there is no security impact, and stating that the performance slow-down is "moderate but your mileage may vary" (about as non-binding as they can get).
Re: We have only ourselves to blame
"...If we had all done 64 bit properly with Itanium like Intel told us to we would not be in this situation so really it is our own fault for following the cheap and simple AMD64 route. We made Intel f**k up..."
The market had built itself around x86 and Itanium would have broken compatibility rather suddenly, leaving a CPU without any software. AMD's x64 extension to x86 was easier for software people to get on board with while they evaluated their life choices on code management. When PowerPC shortly thereafter stopped getting produced and ARM came along a lot of software companies had a bit of a come-to-Jesus moment about how fragile the CPU sector could be and realized that a bit of code-base agility was the way forwards.
Of course this whole time, Intel learned the exact opposite lesson - rather than still paving the way forwards with new clean and well though out ISAs, they reacted like a dog that got tazer'd and really dug-in to the trench of "Hey look! x86 is still compatible with all of your code!!! Don't think about any other ISA!!! EVER!!!" See KnightsCorner/Ferry, etc... They even dabbled in Arm for a bit with the XScale stuff, but never really wanted to impact their server/desktop market with that. Now Marvell has taken that business unit and run with it.
Interesting about RISC-V, I'm on the mailing list for that, and I'm pretty sure with my vague cursory eavesdropping that RISC-V would at least be susceptible to Specter - though they are actively brainstorming on how to eliminate that possibility at the metal layer. The thread is in the ISA-DEV list, with the subject "Discussion: Safeguards on speculative execution?" For those who want to play along at home.
Even the RISC-V ISA guys are still contemplating the entirety of the vulnerabilities, with many "solutions" put forward for simpler work-arounds only leading to new attack vectors - so it makes me wonder how Intel's PR people can stand out there and say Intel CPUs are effectively immune to Meltdown and Specter after this simple patch (which many companies and most end users will never upgrade to - and that so far doesn't include any microcode changes, and no one seems to offer a good reason why that would even work). Answer is probably simple: "because they are paid to".
Lesson, know who is paid to lie to your face for profit, then look elsewhere for answers. ;-) Major kudos to El Reg for the un-spun distillation of the Intel Press Releases article.
Re: @ Pascal Monet "Sigfox's proprietary protocol"
"...You don't know that the argument of 'security thru obscurity' is the case. While this may be true, it may also not be true too... ...Since they claim its proprietary we don't know for sure..."
By the very fact we can't know, that is obscurity, so in this case proprietary = obscurity. It would be better if they said "we use a peer-reviewed encryption protocol based on well-vetted libraries".
"...Having said that... more than likely they cobbled something together that's utter garbage..."
I think you'll find that like the LoRa stuff we've seen at Blackhat and Defcon, there's already enough interest out there in hacker space, that someone has read this PR blurb and said "Challenge Accepted!" which will be followed shortly by a new talk and the stunning realization that the encryption was baked into hardware and can't be changed easily.
Well Sigfox: Let's think about this a bit critically (like the marketing and legal department should have). 1) If the argument is that the RF portion of the wireless spectrum is un-hackable, they will be found wanting. You can't attribute the source of a wireless signal, UNLESS you require multiple receivers to do spacial signal rejection (think the equivalent of phased array microphones to localize a "speaker"), then you put some signature on the emitted signal that is cryptographically unspoofable. The first half of that is extremely hard to do in a commercial setting, the second not so much. However, the other thing going against Sigfox and LoRa is the extremely low bandwidth. There isn't a lot of space to pad a transmission with extra encryption, so they aren't likely to use something hard to break or copy. And without being able to reject interference, the RF link could just be DoS'd - there that's one of the hacker attacks. 2) If the argument is that the Sifox to IP bridge is un-hackable, then they just haven't thought it through enough to know better (I'm pretty certain they didn't build their own servers from scratch and write every line of code in their system - see Equifax for what comes of that naivete). 3) Last, if the argument is that a Sigfox enable IoT device is un-hackable - that's too forward looking a statement to be meaningful. Give a hacker a day with an IoT power meter and they will in all likelihood own the micro-processor - or take a hammer to it, again permanent DoS. For something like a liquid level sensor or other physical process sensor - one doesn't even need to attack the link, they attack the sensor or its connection. It's all about the path of least resistance to accomplish the attack against the target.
RE: No, SPARC is open source. There are two companies that make SPARC chips, Oracle and Fujitsu.
You... may want to take another look at that partnership - Fujitsu is not totally independently producing SPARC processors, or modifying the ISA they way they feel like it. It's more like Fujitsu is a glove and Oracle is the hand inside it - and the tool the gloved hand picks up is more or less Oracle-only software... Kind of makes my point actually - like the MySQL fiasco, and the ongoing Java saga. Because Oracle own the copyright to SPARC, MySQL, and Java - they can and in actuality have the right to do whatever they want with the license at any time, which gives them an enormous amount of power over the users of those items. Just look at how hard Oracle has been going after Google for Java, it's a valid risk having that hanging over one's head.
"...Are they still rejecting that? It must be a fairly hard job to argue that line now..."
Well, no - there is no "door" just a framed hole in the wall. We meant to put a door there at one time... It's not a back door, it's rear hallway that whistles. Enter Goatse. ;-)
Re: Niche Market
"...If that's above your budget you could try a Beowulf cluster of Raspberry Pis..."
All ARM have Trustzone (even RPi). It's not the system space level that is being attacked, it's the lower debug/management level that's being attacked. If you look at the graphic at: https://www.arm.com/products/security-on-arm/trustzone you'll see there is a secure software stack, a non-secure software stack - and debug going outside of both stacks. Though Trustzone hasn't been broken YET (that I'm aware of), I fathom once people actually start looking very critically at it (like researchers did this year with AMT and ME), it will not be long before critical and embarrassing failures of security are discovered there too. This model of having a "secret" system doing work below the known system, is pure and simply security by obscurity. It's much better to just document that dang thing, get the problems found and fixed within a generation or two of silicon, rather than put a decade's worth of silicon in the field and find out the plan was a bad one. Unless Intel's "fix" is to blow a physical fuse on the die as part of a software update to disable the entire block of hardware, I cannot in good faith trust their fix is permanent. Since the current security failure allows analysis of the whole ME system, that means even the fix can be observed already, analyzed and picked apart, then scrutinized for more weaknesses.
Securing a system is hard enough without the ME engine in there, regardless that Intel marketing and public relations doesn't want the ME system called a back door. When you show the world your goatse, all you want people to do is stop looking at it - but trust me, it's hard to un-see from back there. ;-)
"...SPARC is also open source..."
Yes, but SPARC is also now owned by Oracle, and if you've watched what they did with the open source Java library, you'd understand that making changes and including other functionality is at risk of being later litigated. Oracle knows how to kill any standard. Even as "open source" as SPARC or POWER is, I personally think the way forward will be based on RISC-V, and it'll probably even kill off ARM eventually. The whole RISC-V ISA was written from researchers and academia and is all in the public domain. Essentially anyone can take the ISA and push it into their own ASIC or FPGA, and they are wrapping their ISA commits into Linux kernel 4.15. There are already 3rd party vendors like SiFive and lowRISC who are packaging up 4+1 core configurations to work on modern fabs for turnkey stuff running between 16-64bit instructions, with a pre-planned path to 128 bit instructions.
"...Who knows. Perhaps NSA saw what Intel was up to and simply decided to let them get on with it, knowing that they'd fsck it up badly to NSA's advantage.
Why bother coercing / cajoling Intel into slipping in a hidden backdoor when you know they'll build in aircraft hangar sized doors through sheer incompetence... So long as Intel stick to this idea of an ME, there's code there that will likely have flaws..."
I think this is exactly it, and that's why the NSA asked for a "High Assurance" firmware option be made available that is part of all secure system orders - which disables the whole suite of Intel ME functionality. The same guys who found these bugs have been following the breadcrumbs left by the NSA for this research.
Re: NSA specific bug?
> I have to wonder if this wasn't something that the NSA insisted get put in under the whole umbrella of "National Security".
No, No.... you don't get it. The NSA doesn't need to "put things in". The Clipper Chip demonstrated to them that if they applied themselves a bit like they do with TEMPEST, they could find the stuff idiots put in themselves, and just get back to work reading things plain text. As "idiots" who didn't work for the NSA were able to crack the protections. This demonstrated that their adversary was more technically capable than they expected themselves to have to be.
In the computer world companies are pretty well matched on what they can do within a given instruction set architecture, so they have to find ways to "cheat" more performance out of a given ISA in order to get their competition over a barrel. There is an engineering axiom "You don't get ANYTHING for NOTHING". What we have here is the problem being improperly constrained from an engineering standpoint - someone said: "Let's get more performance without using more power or area on the die." Nobody said: "Let's get more performance without using more power or area on the die, and without impacting security".
It's a common theme seen all over tech that security is considered an after-the-fact-add-on, rather than integral to the design. The NSA knows that, and they can demand the full documented ISA from Intel and we'd never know it - the government are also not obligated to inform Intel of any problems found. Kind of like the FBI doesn't need to tell Apple how they cracked those phones after the terrorist shooting. They can just quietly go about their jobs and no one needs to be the wiser (one of the reasons I wish the FBI would just shut up about the encryption back-door thing). I think these agencies talk too much for their own good.
Re: some systems that will have a much worse impact
> Hmmm. Does this mean it will have no impact at all on my WinXP virtual machines on ESXi 4, because (apart from the fact all components are out of support), wasn't this context switch on every interrupt the reason XP ran so crap on ESXi 4?
If you're running an ESXi that old and an OS that old, it doesn't sound like "patching" is in your world-view, so yeah it wouldn't "impact" you more than knowing your system is more vulnerable today than you knew it was it was yesterday. ;-)
Re: Counting chickens?
> The information in this article appears to make a point of it being of greatest impact to cloud virtualization, though the writing is so convoluted, I can’t be positive about this.
Imagine you are running your company's data sharing with manufacturing in a cloud hosted server on shared hardware. This bug basically means that if any other service run in user-space on the same shared hardware had the code required to poke at the kernel, it could bypass ALL virtualization boundaries and take ownership of the whole platform at Priv-0 level. Essentially, if this bug is not quashed and RAPIDLY, the entire virtualization market on these Intel platforms is at risk - as well as the sanctity ad security of the data currently trusted to this market.
> Keep in mind, syscalls have to go through the kernel...
Yeah, and now imagine that you have to stop everything that needs an interrupt so the kernel can lock down and handle kernel level operations while the rest of the user-space tasks sit there and twiddle their thumbs... every time this happens. That's potentially a 5 millisecond hit every 15 milliseconds, and that's where the potential of the performance impact lies. Systems that have a kernel-level VM handler running at Priv-0, will have to UNLOAD anything belonging to a less privileged worker so that it can flush the speculative cache, then handle the kernel task and flush again to continue with the VM guest tasks.
There are some systems that will have a much worse impact than others, for example machines that run over-provisioned guest VMs that need to share a common resource pool will be impacted more during the VM switching (reduces the value of each VM host), machines that run VoIP bridges have a 125uSec interrupt for analog sample-to-packet timing. Machines that do anything with a physical serial port will trip interrupts constantly.
> I think Intel is handling this well so far. They have insurance plans in place to handle these issues and although general operating practice is to wait for a class action suit and settle it in a fashion that pays a lawyer $100 million and gives $5 coupons to anyone who fills out a 30 page form, Amazon, Google and Microsoft have deals in place with Intel which say “Treat us nice or we’ll build our next batch of servers on AMD or Qualcomm”.
Well you may be bitter and think that your buying dollar (or Krone), doesn't provides any power anymore, but the truth couldn't be farther from that. Yeah, so you're aware that Intel will slime their way out of it, that has a PR cost. Yes AMD has CVEs, but I can't recall them having a Pentium 90 math coprocessor issue like Intel, a SATA failure like SandyBridge, a Floating Point bug that needs to be fixed in SW (by third parties), a Management Engine that can't be turned off that leaves systems exposed unless you stop feeding the system power, and now this cache accelerator bug that can adjust performance numbers down to 0.66% of the advertised specs under the only SW fix available (again done by third parties). I'm also aware that the tempo of fairly embarrassing problems are increasing, so if I were a person building a system and saw an increase in the level of ineptitude from a multi-national company, and they only left me with a stack of paper to fill out for my $50 and a still broken POS system that 30% slower than the day I bought it, I'd be so jaded I wouldn't buy their crap any more (and I wouldn't be alone).
If I worked for the Intel PR team in the EU, the first thing I would have thought when reading this article is "uff da..." Even Apple can't get away with a known design flow affecting the product near the end of the design life - see their battery fiasco as of late. Allowing your lawyers and your insurance to cover your screw ups only works a few times... Personally I foresee an investor meeting where someone's head is going to need to be offered as a result of the stock price hit.
So Intel ME is broken, and the VMM is broken, sounds like Intel completely forgot how to make CPUs while they enjoyed their market dominance - probably a good time to switch out to Power or take another look at AMD again IMHO.
Re: The most disturbing thing...
Those trademarks are obtained just like websites, and represent the "public face" of a group. Certainly you understand the risk to facebook.com in there being a faecbook.com that does social media also - and it would be like the senior IT people of facebook.com starting the new company. I worked in consumer electronics, and I can attest that having a product similarly named is a practice a shady company will do to ride the coattails of a competitor. Nothing like racking your brain on the phone with a some panicked installer trying to figure out how he got the software options in the menu that don't match any of the release software, and why it won't even do some of the basic functions it's supposed to - then the email with the picture comes in, and the product isn't ours, but even the product Industrial Design and the remote control got copied...
Just because you're a fake product expert doesn't mean that someone (even a smart person) while under duress is not going to notice the difference. And then there's the other end of the bell-curve...
I've been following the back story to these two groups and talking to others who are closer to both parties, and I personally side with SFLC (the original group).
Re: Or, shocking thought...
You are presuming they didn't consider the operating life. If a highly technical firm like Apple has to slow down the phone due to admittedly engineering-understood battery limitations in models as recently as the iPhone 6, doesn't that elude that they they expected the product life to be short? They could have managed the battery life issue better following experience gained from iPhone <6. Either way I see Apple getting their @$$ handed to them. The lawyer will ask the question "What is the product design life?" No matter how they answer that question, Apples loses IMHO. "Oh it's two years maximum" = PR disaster as people would be finding our from the horse's mouth they are paying nearly a grand for a throwaway product - doesn't matter if it's made of gold if you're throwing it away after a few years, only the upper 0.01% can afford to do that on a regular basis (ah, thanks Instagram for showing us that). Or "It's expected to last a minimum of 5 years" = product defect = payout + PR disaster. There are basically two ways how that can be answered "We are shady/dirty" or "We are incompetent" with various mixtures of those two answers in the middle.
Personally I think it'll end up that people will be told that any phone only has a design and market life of 2 years. Screens, cameras, cellular technology, Bluetooth revision, connectors, etc... which all make the foundation of a mobile device - change too fast and too frequently for a product ecosystem to really exist around a single design anymore. An $800 phone sounds terrible, unless you are having a cell phone company subsidize the phone with higher contract costs spread over two years, at which time you'd be able to upgrade to the next device while continuing your carrier lock-in, a carrier that gets high enough turn over they can use the excuse that the minority to hold on to their old stuff are no longer supported as they are running obsolete radios... Causing the rest of their customers to have to re-buy-in. I'm not optimistic enough about the world to believe that companies aren't collaborating on this stuff off the record outside the reach of regulators, there's just too much money at stake for there not to be anything underhanded going on IMHO.
Re: Insecurity by obscurity
> [...] There is no silly naive "once someone figures out how to understand what you are doing, your logical mistakes will become very public".
That can only happen thru spies.
Competitors and governments secret agencies are behind these black ops.
I think you are giving WAY to much credit to the large pool of lazy inept software engineers employed in a wide distribution of jobs in tech who make the lives of the energetic properly skilled and qualified engineers lives hell. You must not also be a frequent reader of The Register either, software exploits and bugs are a common problem in tech, and very widely reported. Don't believe me? Look up "CVE Reports" on Google - those reports in the system are just the ones that were honestly reported to be corrected. You don't hear from spies about spies' work - they typically play that stuff close to the chest and don't tell anyone as it would make their job harder.
When you get down to it, a machine that runs machine code has to keep it somewhere for it to be ready to run. If you can figure our what the instructions are, then you can find the mistakes.
If all you do all day long is look at C++ code and you put a === where there should be a ==, you aren't likely to see that without help (rules checker, good compiler, third party, etc). Making mistakes is easy, getting it right is hard - humans make mistakes.
And as someone who works in Tech, I can tell you that if a piece of code or logic "reasonably approximates intended functionality", there is little incentive to revisit it unless a problem is found that causes a manager somewhere with task scheduling power some grief. If you then hide your code and refuse to publish the specifications for any peer review, you are only delaying further debugging by an adversary, not preventing it. The adversary will never care about honesty or rules or damage, imagining they do care is security suicide.
Re: Who is behind all this bashing against Intel ME , uh?
> [...] Why no one is checking coding flaws in AMD, IBM Power, Oracle SPARC, ARM ? They all have the same as Intel Management Engine chipsets running full embedded OS that don't have the specifications disclosed either.
Well, 80/20 rule: first 20% effort gives 80% results, last 80% only gives final 20% results. If you want to get into as many distributed platforms are possible with as much RAM, CPU power, and storage resources attached to the services you want to compromise - do you attack AMD, POWER, SPARC, or ARM? No, you go after Intel x86. Being a big target means taking the most shots. Ask, Windows vs Linux who is attacked more?
If you attack the OS and they have good security practices in place, but you find there is a low level OS that is not protected that can circumvent the protections the User's OS has in place - would you continue attacking the hardened User OS or the insecure OS below the security features? This attack makes perfect sense to me...
> [...] Also all this easy hacking of Intel ME how? The full hardware and software specifications are not public so other than government spies and competitors spies there is no way to steal that data to hack the system either.
Don't underestimate the power of common debugging tools in the hands of interested/committed engineers... ;-) JTAG, I2C, SPI, and USB are not alien technologies to most engineers, and even hobbiests are getting in the game now that ARM and FPGAs are getting into the masses hands. All of those interfaces have fairly standard communication methods for data to go over them, which any person familiar with can peal apart. You give the complications of modern technology too much credit for being an obscurity wall IMHO.
Re: AMD and ARM
It resides in the PCH (what we used to call the "chipset" consisting of Northbridge and Southbridge). This is why they are pushing the blame for support to "vendors", the BIOS ROM contains the ME code.
This is the full scale of the problem: the vendors first need to give a damn about your platform, then they need to download the patched ME runtime from Intel, then they need to recompile their BIOS with the new Intel ME runtime blob included, then sign the build so that the PCH will allow a valid BIOS flash, then publish the new BIOS - all that before we have to deal with the large swath of end-users who probably don't know enough to care or couldn't be bothered to figure our each vendor's BIOS update process (I'd also hazard a guess, most users will never update a BIOS after retail sale). Meanwhile, all a hacker has to do is get control of an ME OS while running, and block any attempts to update the firmware (because why stop a good thing!!). I'm sure Intel's lawyers are going every bit of marketing over the last 10 years to quickly scrub any evidence of "promised security" from the written record. ;-)
Intel PR people say "Yay we found a bug with the help of security researchers and published a patch! Job done!". No - now they get to sit back and realize how bad a business decision putting a hidden computer and OS inside everyone's computer below the reach of the common users and security market was, as the world's hackers spend the next few years fine tuning their persistent hacks that block any effort by Intel to fix this mess. NSA was smart at the beginning to ask for the High Assurance flag in BIOS ROM, basically disabling the threat from the factory. They likely saw the writing on the wall, and probably let this happen knowing that they were basically being handed a globally distributed backdoor by Intel (either on purpose or by accident, the outcome is the same).
This is also why having a single vendor effectively have a monopoly over data-center hardware is a potentially catastrophic global risk. If they are the only ones owning the market and they screw up, we all have no recourse.
Re: Insecurity by obscurity
Not usually for as long though for something as low level. ME in its various forms has existed since the CORE line of processors came around. That's 10 or so years of hardware deployment, potentially tens if not hundreds of millions of deployed platforms (not just desktops, laptops and servers - embedded devices too). What is a given though, is that if you rely on obscurity for security (rather than doing good security analysis, and having a third party double check your work), is that once someone figures out how to understand what you are doing, your logical mistakes will become very public - as has happened here.
Re: свобода - это рабство (Freedom is Slavery)
For the record, I neither up or down voted your comment. I'd rather talk about it.
> [...] Really? Is that the same Government that lets tech companies get away with pretty much anything?
Oh you mean those tech companies who are funding and heavily lobbying the government to continue to erode our power in order to protect themselves? Yeah, the tech companies are not much better IMHO. I definitely believe Google internally changed their legal definition of "evil" so they could keep the facade of "Don't be Evil" in their motto. Think Ajit Pai isn't talking to Comcast, or Verizon, or AT&T off the record? There's no way he could be saying the things he's said or doing what he's doing without being bought and sold - and no one in power is stopping him.
> [...] Can you write dumb shit like your latest Internet opus, without fear of consequences or reprisal from the Government?
Nope, no I can't. This is on the interwebs forever - and if I get arrested for anything later, a gung-ho prosecutor can probably find it and twist or partially redact my words to change the context to fit their narrative while sending me up for some viciously up-charged crime to make an example out of me. The phrase "has a history of rejecting authority" comes to mind "just look at this online post!" they'd say. I'd rather frame it as "questioning authority", but if I'm in court later I have to deal with "peers" like you who would likely eat up the prosecution's story... Because in my country, YOU are part of the government by voting and serving on a jury, and I'm already catching reprisals from you. ;-)
> [...] Can you vote? Can you form a political party? Can you run for office?
Yup can do all of those things - but the effectiveness of all those things has been reduced to insignificance. I vote in what is effectively a two party system, in a state that votes differently from me on balance. When I go to another place in my own country and it is learned where I am from, assumptions are made as to my political leanings. That, yes does have an effective impact on how I am treated. Sure I could form a political party, and it would be an absolute waste of time and money as even if I could throw billions of my own dollars at my newly formed party to attempt to compete with the two dominant parties, the campaign donation laws passed by the two parties make that illegal. I could run for office, but when you sign on as one of the two parties that is likely to win, you have to accept their backing to be nominated and that seems to come with strings attached which would compromise my integrity.
> [...] Can the right to work be taken away from you? Is your religion - whichever that may be - being persecuted? Conversely, are you subject to persecution because you have no religious affiliation -- i.e. agnostic or atheist?
I am agnostic, because I see religion created by man (neuter) for man (neuter), to be fallible though it is taught as infallible - thus I don't care about religion, not an atheist how needs to shove that logic down people's throats. That said, I don't live in China, and I'm not being murdered for my organs by a totalitarian state - so there's that.
> [...] Can you own a gun?
Where I live (California), they would like to tell me "No" and for no other reason that for them to FEEL safe. It scares the crap out of me that there are people in my Government that just want to do away with those pesky constitutional rights because they are afraid.
> [...] Can you get married?
If I was gay in certain areas of my country, you might be surprised to find that the answer would be "No".
> [...] If you have children, can they attend kindergarten, school, high school, college and get an education?
Try NOT sending your kids to school see what happens.
> [...] Can you own property? Do you own property?
Try not paying taxes on the things you own, to see if you really own them.
> [...] Does the Secret Police knock your door down, with a ram, at 3AM, and take you and your family to an undisclosed location, in a white armored van marked Wedding Cakes?
Typically the police don't make it a secret when they do things these days, because people are so desensitized to being roughed up, detained or searched without cause - that if the police came to my door at 3AM, the most that would happen is a neighbor yelling "Be Quiet!" to me while I'm kicking an screaming. Police are so "well trained" on what passes for "bomb components" that if you were to happen to have both a full gas can and a few spare road flares in the same garage (never mind not stored anywhere near each other!) they could "lawfully" detain you for running a bomb factory. Don't even let them near your household cleaners... and oh my gosh he has a soldering iron! Once a life is ruined by those actions, trust me it doesn't go back to normal, but everyone else forgets about it and moves on.
So - in summary response to your claim that I'm an "internet crazy", I'd counter are you and I really as "free" as you'd believe? Now your moment of meditation and reflection. You offer measures for freedom, but have you noticed how constrained those definitions have become? Is your line in the sand something that can easily be walked around without crossing it? Are you even equipped to notice?
Re: “Tech people need to tell policy people about the next coming threat.”
The problem is, for the past 20 or so years the Government has made it crystal clear that private tech is their adversary, to the point of prison and total annihilation of its own citizens rights. Now they want help, but we have Pai taking away Title 2, and Congress is still exchanging butt-plugs with RIAA/MPAA while stomping on fair-use...
I'm not saying I advocate it, but for him as a National Security Analyst, they should be concerned if they were not considering that the destruction of the NSA or CIA in their current form might be a net positive for the whole planet - I'm certain that there are people out there who not only believe that, but are actively working towards that end.
If you make it a crime to fight crime and investigate new ways people commit crime, the only possible outcome is anarchy.
Then there is the other side - you and I as readers of The Register are more than likely technically inclined. While The Register reported on this story, I don't think the content the Reg reported was intended for us as an audience. Government Bureaucrats are an advanced persistent threat, and need to be treated as such (with a firewall, IDS/IPS, blue-team, etc...). The audience for these quotes was more likely a skittish and non-technical Congress, who wants to know what money and power they need to throw at an agency to "make the bad man stop"... We see that with the FBI holding their warrants in their hands looking solemn after a mass shooting, because they didn't work with Apple the day-of to unlock a phone or go through the legal requirement of getting a judge to sign a warrant in the first place - "No, just make a permanent back door" they say... then they go in front of cameras and Congress and say "Look! they said 'No we won't help'!!! Make them do it with a new law!!!!".
Readers can spend all their effort knocking our current President if they want, but the way I see it, once a Government gets to a certain size and power, it tends to create its own "gravity" for more size and power. Companies cut staff due to redundancies, I think it's time we cut the size of our own so that we can even find those groups who are doing the bad stuff inside our own government, and focus our resources on those groups and programs that actually do some good.
Re: Person V Person.
At the risk of responding to too many comments - when you are constructing a wooden building and you know you don't have the fire sprinklers installed, and you see one of the workers pouring gasoline on the wooden structure to burn out a hole from one floor to another to correct for a mistake in the floor - about the only rational response to that for everyone's safety is to dog pile that idiot before they light a match. Sure they'll feel ganged up on and made to look a fool, but they WERE being stupid, and the building will stay standing as a result of the intervention. Some people simply take the most expedient path to a "solution" for their myopic problem, without considering the collateral damage they can cause to the overall project. Confucius Says: Never use a cannon to swat a fly!
He probably wants to have Thanksgiving with his family this week. Not everyone lives in a dark hole in some Google incubator... There's this thing called "outside" and "living" that doesn't require a computer ;-)
Personally, I understand and agree with Linus 100%. Adapting his comment to those users with a life full of experience in Windows, what he's complaining about is rather than an error log entry being generated for a problem, the outcome proposed is an intentional Blue Screen of Death (Windows equivalent of a kernel panic). So, YES, I would be absolutely LIVID if a developer came and told me that my machine should BSoD on me because they didn't test their code. There is value in putting out warnings first and collecting data to see if you've correctly constrained your new patches, rather than borking a bunch of systems you didn't consider, and having to "apologize" (emergency patch) later. Be unhappy with Linus if you want, but I think he's doing them (the Google team) a favor by aggressively ridiculing them now, rather than having their brand damaged as a result of their naivete in coding going public and becoming the target of everyone's ire as their formerly working products brick. Software should (as a first principal) be designed to survive coding mistakes, especially down at the base OS kernel level, since programmers are famous for making coding mistakes. You can't approach software security assuming everyone "got it right" at the outset, that is utterly stupid to assume, we know it is NOT the case.
I guess we just need to whip out the magnetic undersea mine triggers again. If they are pushing unshielded water with a giant magnet that should be more effective at triggering a mine than an iron-based ship passing over it... Either that or we start looking at the local electrical charge of the water. Since they have to electrify the water for a motive force to be applied using magnets, I'm sure we can detect this in open sea. That's probably one of the reasons the US Navy never went with this tech. That and you can never get anywhere near a freshwater bay.
Re: messing with meshes
Over WiFi (thereby using WiFi spectrum). Also see definition of "panacea" before arguing it's NEQ "solution".
I know what mesh is, I run B.A.T.M.A.N advanced on a few 900MHz WiFi radios as a mesh "backbone" around my property, then more APs with smaller cell-like channel partitions and antenna arrays to provide access to regular devices.
The point is that if you have a internet connection, then you need to transmit that data out to the device over wireless hops, then back to the point of access over more hops. Every one of those hops is a time slot on a channel that another device can't use - because they all happen in the same channel space the regular devices use. Modern consumer access points don't give the home user the control to tune the radiation and reception pattern to their own property (even though most AP n/ac chipsets can do beam forming). You would then "train" the AP to only accept signals from inside its reception area, and down-tune the gain so that the signal drops off outside the bounds. But it's probably a good thing too - more home users aren't ready for that level of control and responsibility.
I did an installation in the early 2000's at HP Labs' campus in Palo Alto with original Lucent 802.11b PC-cards. More devices doesn't beat good RF planning, and I think we do a disservice telling consumers that they "...don't have to think about it, just put a few of these in every corner of your house!!" Doing an ACTUAL distributed antenna system (DAS) and down-tuning the AP(s) so that it only covers the intended area, and by antenna form-factor and placement rejects other signals, is far superior to deploying a mesh. Less devices "talking" in given, limited channels means more channel space available. Period.
Re: messing with meshes
So it looks like my plan to make every room in the house a Faraday cage and drop an ac-AP in each room is going to mean my house is the only one on the block with decent WiFi bandwidth in every nook? Bad enough I have to put my cable modem in a Faraday cage to keep it from eating up my channels.
Mesh APs are still not a panacea for crap WiFi performance. It's not just signal strength that matters, but signal integrity - if everyone in the room is shouting as loud as they can, it's hard for two people to talk to each other. As with WiFi, you can't fix all your problems with more WiFi - as it is all these problems look like nails I can fix with my hammer. ;-)
Many of those lanes will also be consumed by NIC and other on-board devices. It's probably the same two x16 and one x8 setup Intel has rinsed and repeated for a decade - still wondering when they'll get the memo that people want general purpose slots to plug items into their general purpose computer...
.. ..-. / -.-- --- ..- / -.-. .- -. / .-. . .- -.. / - .... .. ... then a US Navy fondleslab just put you out of a job
Vulture: .... .- --..-- / .-- .... .- - / .- / -.-. .-. --- -.-. -.- / --- ..-. / ... .... .. - . / - .... .- - / - .... . -.-- / .- .-. . / --. . - - .. -. --. / .-. .. -.. / --- ..-. / -- --- .-. ... . .-.-.- / .. / .-. . -.-. .- .-.. .-.. / .- -. / .- -. . -.-. -.. --- - . / .- -... --- ..- - / -- --- .-. ... . / -... . .. -. --. / -.-. .-. .. - .. -.-. .- .-.. / --- -. / - .... . / -... . .- -.-. .... / .-.. .- -. -.. .. -. --. / .- - / -. --- .-. -- .- -. -.. -.-- / -....- / .-. .- -.. .. --- ... / ... .... --- - / --- ..- - / .- -. -.. / .-- . - --..-- / --- -. .-.. -.-- / .... .- -.. / .- / ... .. --. -. .- .-.. / .-.. .. --. .... - / - --- / .-. .- -.. .. --- / .- .-. - .. .-.. .-.. . .-. -.-- / -.-. --- .-. .-. . -.-. - .. --- -. ... / -.--.- .- ..-. - . .-. / --- -. . / -... .- -.. / ... .... --- - / .-- .. .--. . -.. / --- ..- - / - .... . / -.-. --- -- -- .- -. -.. / ... - .- ..-. ..-. -.--.- .-.-.- / -. .. -.-. . / - .... .. -. --. / .- -... --- ..- - / -- --- .-. ... . / .. ... / - .... .- - / -.-- --- ..- / --- -. .-.. -.-- / -. . . -.. / .- / ... --- -- . - .... .. -. --. / ... .... .. -. -.-- / --- .-. / .-. . ..-. .-.. . -.-. - .. ...- . / - --- / ... . -. -.. / .. - .-.-.- .-.-.- .-.-.- / .- -. -.. / .- / -... .-. .- .. -. / - --- / .--. .-. --- -.-. . ... ... / .. - .-.-.- / - --- --- / . -..- .--. . -. ... .. ...- . / - --- / - .-. .- .. -. / -- -.-- / .- ... ... / -....- / .. ..-. / - .... . -.-- / -.-. .- -. .----. - / - .-. .- .. -. / .--. . --- .--. .-.. . / - --- / .-.. . .- .-. -. / .- / -.. .. ..-. ..-. . .-. . -. - / .-- .- -.-- / --- ..-. / - -.-- .--. .. -. --. / - .... . / .-.. . - - . .-. ... / - .... . -.-- / .- .-.. .-. . .- -.. -.-- / ..- ... . / .-- . / .- .-. . / ..-. ..- -.-. -.- . -.. .-.-.-
Re: Defence in Depth is really about gaining time to allow a measured response.
Glad to see others talking about physical security principals with respect to network security. If we want to be frank, yes defense in depth is about delay - with it being the hardest and longest to get to the most valuable posessions. It is one of the key aspects of physical security's four stages:
* Detect - let's you know something is wrong
* Delay - gives you time to do something about the threat before it concludes its aims
* Classify - take a moment to come up with a balanced solution to the problem, have contingencies!
* Respond - act to mitigate/eliminate the threat.
Most articles talk about doing defense in depth, but don't talk about why it's done the way it's done. If network admins considered how physical security handles threats rather than assuming it was possible to prevent bad actors (wise man once said: the only secure machine is the one which is unplugged from any networks, powered off, shredded, then incinerated - and the ashes spread from an airplane into a tornado). The author of the article has a good head-start, understanding what you have and what your risks are - this will help focus the defensive measures towards the "crown jewels". Unique IP, customer data, and electronic business identity (crypto-keys, and the like), are the crown jewels which should be protected at all costs.
Things like the HVAC system are not as sensitive and should not be housed in the same rings of security. Much like a castle would have a town outside the bastion walls which would be abandoned during a siege, as the residents ran inside to help hold the fortification, some parts of a network must be able to be considered sacrificial. You also didn't see a lot of cases where an inner layer was depended on the outer layer to hold up - using the castle reference again, if the castle could only stay secure as long as the soldiers were given food and water, but someone had to go outside to hunt and get to the well to support the soldiers, it wouldn't be long before the castle fell.
A business can probably lose a day of output due to lost productivity (even at a cost of millions), versus having brand damage or IP theft continuously sap trust in an organization. Unless of course losing a day of work is the trigger of said brand damage - see recent British Airways fiasco. That was obviously a serious miscalculation of the risks of each sub-system interacting on combined/simultaneous events - and a further illustration of how each protection layer needs to be self sufficient, not inter-dependent in any way.
It's also important that what is available in outer layers do not become tools for those attempting to overcome the next layer. Have a window to keep people out, but also have large rocks in a planter? That's a burglar's "key". Built a tower to keep knight from getting to Rapunzel, but leave your extension ladder in a shed in the yard? Hygiene is just as important as having the right defenses - if one can't see people walking up to the fence, you can't detect it, thus the delay of climbing over it doesn't do any good. If you clear the trees 1km from the fence and mow the grass, you gain that much more detection and delay capability. Likewise, if one starts looking at the traffic that comes and goes into a facility, control it and filter it - and you will be able to see the obvious attempts to break a window... Being able to define things that shouldn't happen (black-listing) is the result of good planning on what should happen (white-listing). If one has correctly constrained the scope of their environment, anything out of the scope can be considered wrong (attack).