IKEv2 IPsec via StrongSwan or LibreSwan really isn't that difficult on Linux. Problem is a lot of these corp vpn products that don't have a Common Cirteria or FIPS mode don't support it, and many of these other technologies have to do lame hacks to get things like NAT traversal to work.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Well, it seems to me it is designed to functional specs, where the PRD phase probably said something like "it should work like a person, but without risk of death" and then they went about figuring how to build that. Humans don't have snaky arms with additional articulation points, so how would someone in a VR motion capture suit control that?
There is no formal verification at EAL4. That is at 7. EAL4 is "methodical" design, testing and review. A lot of crap got EAL4, like Windows XP.
Besides, you can't get an EAL evaluation under NIAP anymore, it is Protection Profile only in the US. Unless you take your stuff to Europe for CC certification you're out of luck (BSI loves EAL) if that's what you want.
The EAL system has a lot of holes in it that enable crap products to skirt the spirit. Not that the PP system doesn't, but it is harder to do (usually)
Code reuse is a fundamental tenant of secure software development lifecycles. You reduce the chance that you introduce new vulnerabillities by limiting the amount of new code per project to the core business logic and leveraging existing modules for the support infrastructure.
That said, if the module you reuse has problems then you aren't necessarily better off. The modules need to be vetted and maintained appropriately. Code reuse isn't the problem so much as taking random crap from the internet that solves your problem without assessing its suitability for inclusion given your threat model or properly assessing it for vulnerabilities.
Monoculture can be an issue from certain perspectives -- flaws in the libssl portion of OpenSSL affect a huge percentage of the internet. However, they only need to be fixed once and consumers of the library can all receive the update, assuming proper patch management in the environment. If your company uses 15 different libraries to perform a specific software function across different product lines without a basis in engineering requirements constraints, you're doing it wrong.
Security being a subset of correctness, I think overall it is b.s. to say code reuse is a problem. You just need to make sure you are reusing correct, vetted and maintained code. I.e., don't take strange code from someone's github to use in your enterprise software without reviewing it.
They can be used to scan emails coming in our out of your mail server; scan files on web servers for thing that might there to be infect other end points, etc. As to how common it is in the "real world," I don't know. I remember arguing about a requirement to support Mcafee with DISA a while back because running a competitor's product on the control plane of our own certainly was a non-starter, but they had a requirement around it. We won the argument, but it took some doing.
Well, I was thinking more of the buildings/properties that he licenses his name to, but they're funded and built by other entities. They just license the Trump name for branding purposes. BlackBerry has a lot of brand recognition held over from the old days when they were doing far better than they are now. I have good memories of their hardware build quality, etc. They were like the the Thinkpad of "smart" phones. Now they've gone down hill and are only BlackBerry in name, just like Thinkpad.
But in the Thinkpad case, Lenovo makes the hardware and owns the brand. IBM didn't keep the brand name and slap it on someone else's computer, like Trump does with buildings and BlackBerry now does with phones.
Slashdot Mirror
IKEv2 IPsec via StrongSwan or LibreSwan really isn't that difficult on Linux. Problem is a lot of these corp vpn products that don't have a Common Cirteria or FIPS mode don't support it, and many of these other technologies have to do lame hacks to get things like NAT traversal to work.
I like technologies with ISO, ANSI or IEEE standards, not documents saying you can't use it if you're a meanie.
Also, they straight bought out BC, meaning a major root CA owns a major SSL/TLS intercept platform as well. But of course, we can trust them...
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.
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.
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.
Frankly, it would change my buying behavior if they did this. Until then, all things being equal, i'm plenty happy with my new Xeon-based laptop.
No, revenue is just income. Profit is revenue minus cost.
Does mental illness lead to owning a cat, though?
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.
I'm also quite certain that Trump isn't at all likely to invade Russia heading into a winter, so there is that, too.
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.
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.
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.
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.
You're right, but given that I was typing with my thumbs first thing in the morning before coffee, you get the point I was making none the less.
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.
No, that would be this one:
https://xkcd.com/224/
Well, it seems to me it is designed to functional specs, where the PRD phase probably said something like "it should work like a person, but without risk of death" and then they went about figuring how to build that. Humans don't have snaky arms with additional articulation points, so how would someone in a VR motion capture suit control that?
There is no formal verification at EAL4. That is at 7. EAL4 is "methodical" design, testing and review. A lot of crap got EAL4, like Windows XP.
Besides, you can't get an EAL evaluation under NIAP anymore, it is Protection Profile only in the US. Unless you take your stuff to Europe for CC certification you're out of luck (BSI loves EAL) if that's what you want.
The EAL system has a lot of holes in it that enable crap products to skirt the spirit. Not that the PP system doesn't, but it is harder to do (usually)
Code reuse is a fundamental tenant of secure software development lifecycles. You reduce the chance that you introduce new vulnerabillities by limiting the amount of new code per project to the core business logic and leveraging existing modules for the support infrastructure.
That said, if the module you reuse has problems then you aren't necessarily better off. The modules need to be vetted and maintained appropriately. Code reuse isn't the problem so much as taking random crap from the internet that solves your problem without assessing its suitability for inclusion given your threat model or properly assessing it for vulnerabilities.
Monoculture can be an issue from certain perspectives -- flaws in the libssl portion of OpenSSL affect a huge percentage of the internet. However, they only need to be fixed once and consumers of the library can all receive the update, assuming proper patch management in the environment. If your company uses 15 different libraries to perform a specific software function across different product lines without a basis in engineering requirements constraints, you're doing it wrong.
Security being a subset of correctness, I think overall it is b.s. to say code reuse is a problem. You just need to make sure you are reusing correct, vetted and maintained code. I.e., don't take strange code from someone's github to use in your enterprise software without reviewing it.
They can be used to scan emails coming in our out of your mail server; scan files on web servers for thing that might there to be infect other end points, etc. As to how common it is in the "real world," I don't know. I remember arguing about a requirement to support Mcafee with DISA a while back because running a competitor's product on the control plane of our own certainly was a non-starter, but they had a requirement around it. We won the argument, but it took some doing.
Well, I was thinking more of the buildings/properties that he licenses his name to, but they're funded and built by other entities. They just license the Trump name for branding purposes. BlackBerry has a lot of brand recognition held over from the old days when they were doing far better than they are now. I have good memories of their hardware build quality, etc. They were like the the Thinkpad of "smart" phones. Now they've gone down hill and are only BlackBerry in name, just like Thinkpad.
But in the Thinkpad case, Lenovo makes the hardware and owns the brand. IBM didn't keep the brand name and slap it on someone else's computer, like Trump does with buildings and BlackBerry now does with phones.
and not even as much of it as they let on.
Are they the Donald Trump of phone vendors now?
It is with "glutin" these days