Become a fan of Slashdot on Facebook


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:No it doesn't (Score 1) 202

Yup, nothing is ever fully trusted. Unfortunately, trust is a much-used word in security, and govt tends to shove it into terms of art, such as "trusted channel" or "trusted path," which show up in common criteria.

One of the major issues I have with CC is that there is a lot of hand waving in the threats and assumptions section, including the assumption that the device is being administered or used by people who aren't actively hostile or incompetent. That's an awful lot of hand waving, and then leads to a situation where in technical terms we can talk about trust, but in any meaningful way we really can't. I can provide assurances around the abilities and configuration of two devices. They can talk over a "trusted channel," (i.e., a cryptographicaly secure channel with authentication by certificate or PSK, between processes on two devices) and be administered by trusted path (a similarly cryptographically secure channel between a remote administrator and the device).

A bad actor leveraging SSH to remotely connect to a device and do bad actor things is leveraging a "trusted path" just as much as the good actor.

So, yes, while "trust" may be a technical term/term of art, absolutely take with a grain of salt the trustworthiness of the secrecy of the communication based on factors such as strength of cryptography providing the confidentiality, integrity and authenticity of the channel, the likelihood that the endpoint (including your own) is compromised, and the likelihood that the remote terminal operator is compromised in some what (being blackmailed, actually a mole, has been replaced with someone else, etc.).

End of the day, though, "good enough" is probably usually good enough, residual risk will never be removed, and at some point you just need to live your life without being overly paranoid all the time.

Comment Re:No it doesn't (Score 3, Interesting) 202

I couldn't agree more. However, a lot of security technologies and methodologies seem to be predicated on the assumption that both terminals in a communication remain uncompromised or, in some (older, more troubling models), the assumption that by connecting two untrusted peers together over a trusted channel that the peers somehow inherit a general trust property, rather than just the trust implicit in authentication between endpoints.

That said, most of the public discussion seems to be go like this: either a), "crypto is great and as long as we use crypto, we're totally secure!" -- ignoring the fact that one compromised endpoint compromises the confidentiality of the channel, or b) "z0mg!! the endpoints can be compromised, so what good is encryption!? Signal is defeated!!", which is equally absurd.

People freak out about the ability of the CIA to conduct targeted operations because it is in the news, and people are bad at risk estimation and therefor threat modeling, especially if they aren't security professionals (i.e., most people). The CIA isn't necessarily in my threat model. However, mass surveillance is, because I'm part of the masses. Targeted actions by non-US foreign intelligence services have been, due to employment. So has industrial espionage, criminal hacking, and hacktivism. One can assume, however, that any non-US threat actors have at least the same level of sophistication for targeted endpoint compromise, even if they don't have the sophistication to suck all the comms out of the air.

So, absolutely defense in depth. But part of that is recognizing that if I put two untrusted endpoints together with a trusted channel, I don't magically get two trusted systems. I get two suspect systems that are able to exchange messages of dubious quality over an overt channel that is less susceptible to passive attack.

Comment Re:No it doesn't (Score 2) 202

Well, yes and no. Providing data-in-transit protection between two endpoints only mattes if both end points are of an equally trustworthy nature. Hat is a combination of security of the device, assumption that it has not already been compromised, and that the operator is operating in good faith.

Sending a confidential message via trusted channel to another terminal being operated by Loud Howard who will read the message out loud to himself subverts all the technical controls, too, if he is being listened to.

Comment SCAP (Score 1) 43

How is this fundamentally different than using SCAP or OVAL content to do a STIG check against a host and then apply remediations against findings? Other than it will hopefully allow "normal" users to understand what the problem is and what to do about it. But normal users probably aren't going to grab an open source security scanner and then follow the recommendations. They would then be abnormal users, by definition.

Comment Re:What are Rust's prospects like? (Score 1) 339

You know where I've never seen a code of conduct? In an ISO, ANSI or IEEE standard. The threat to long-term viability of languages or platforms for serious projects is lack of rigerous standardization which can allow multiple competing yet interoperable implementations to exist that don't have to fall to the whims of any one company, foundation, or message board.

Comment Re:Security. (Score 2) 261

Much like the transition to cloud, most of the "eyes on glas" type jobs will be in MSSPs, and they'll have staff reduction sue to AI and workflow automation just like almost everything else. I have a really good sub niche right now that has low
Competition and goes widely unnoticed but pays a whole lot. I plan on milking it as long as I can, which is a lot longer than I was going to live with the stress from security "operations," that's for sure.

Comment Re:Security. (Score 1) 261

Insurance (risk transference) is one method of risk mitigation. However, insurance companies are, by and large, extremely good at risk analysis (they have to be to stay in business). The likelihood of an insurer paying out on a breach where the insured party can't show that they performed any sort of other risk mitigation is going to be extremely low.

Otherwise, I agree with you and your comment fits my experience to a T.

Comment What price point, and what kind of nerd? (Score 1) 232

Rolex originally marketed the Milgauss towards scientists and engineers who needed an antimagnetic watch. I have an Omega Seamaster >15'000 Gauss due to my need for higher levels of anti-magnetic resistence but a love of mechanical watches. The TAG my brother in law gave me for a wedding present wouldngain 2 minutes in the course of the day at work because of the EM from all the gear. Next one I go for is probably. A Breitling Navitimer; can't beat the useful nerdiness of a circular slide rule.

I also do have a Citizen Eco-Drive (solar power) that syncs the atomic clock signal. If you're totally about precision, those, or the GPS-synced watches from Citizen and Seiko are pretty cool, too.

Not having had a digital watch since 6th grade, I have nothing to offer on that front.

Comment Reasons: standards, size and man pages (Score 1) 286

C is a very small language with a modest standard library. The language itself has ANSI and ISO certifications. The standard C library is largely defined by POSIX. I con't have to hold much in my head by way of language constructs or reserved words, etc. and any other programming languages derived their syntax from C, so it will get reenforced often (except the weird ways to use pointers).

If I have a question about a standard libc function, the man pages will be there on my systems whether it is FreeBSD, Solaris or Red Hat. Most of the time, a question about C can be equally expressed as a question about Unix-like systems because of this.

C and POSIX are well established and have been through a rigerous standards process, so unless you're interested in a fancy new compiler feature like SafeStack on clang/llvm, you don't really have a lot to learn or relearn once you have it down. No one is about to change how C represents strings or any of the like between versions of compilers for reasons of "just because," though. You may need to look up the specifics of a third-party library if it didn't come with man pages, but that might not show up as a search about C.

Other languages with huge base libraries which aren't part of the OS's standards definition, multiple programming paradigms, lack of standards causing if shifts between versions, etc., are almost certainly going to get more people heading to Google because they have to.

Slashdot Top Deals

I haven't lost my mind -- it's backed up on tape somewhere.