14 ms·

NSA Network Infrastructure Security Guidance [pdf]

130 points by slacka 5y ago

dhx 5y ago
Use of firewalls in series from multiple vendors sounds like a good idea in theory but in practice, does it not make it easier for an attacker to exploit the network? Instead of the attacker having to find a vulnerability in a single product, they can instead find a vulnerability in one of multiple products (a much easier task). Given that every network device communicates with a central authentication/authorisation system, a central logging system and likely central patching, configuration deployment, etc systems, all it takes is to find a vulnerability in one of multiple firewall products, then find a vulnerability in one of the central systems used to mange the network. I'm also perplexed why there is mention of "traffic inspector" and "full-packet capture device" given that almost all traffic traversing a network nowadays is encrypted. Perhaps more useful today would be creating a good understanding of the normal traffic flows so that alarms can be configured for abnormal traffic. For example, perhaps no more than 100 requests to an authentication server occur per device per day. Or patches for a system are no more than 1GB so seeing 1.1GB or more transferred across the management network per day per device would be abnormal.
- throwbigdata 5y ago
  That’s not how “in series” works.
- vlovich123 5y ago
  > Instead of the attacker having to find a vulnerability in a single product, they can instead find a vulnerability in one of multiple products (a much easier task) I’m not sure I understand this argument you’re making. If you have them in series then you have to find vulnerabilities for all of them before you can talk to any other system. A vulnerability to one of them only lets you punch through that one layer. In theory of course. I think this advice may not be well flushed out though. For example, if the firewalls are running on the same appliance and have poor isolation/misconfigure settings, an escape in one can bypass the entire set of firewalls (which is maybe what you’re implying?). Having totally isolated firewall machines is inefficient from a capex perspective (more machines than needed for your load) and in general multiple vendors increased your opex costs too (you now need employees that are proficient with multiple vendors which ends up meaning you have teams with dedicated experts per firewall, you have to build automation for multiple vendors with non-standard APIs etc). The bigger problem though is you’ve sacrificed availability which is now divided by N times because every layer you’ve added has to be functioning perfectly or the entire system is down (and if it’s not you’ve implemented this advice incorrectly). I think not mentioning this security/availability/cost trade off is a disservice.
  - dhx 5y ago
    The scenario I had in mind is Firewall A and Firewall B are in series and they're different products from two vendors. Firewall B is found to contain a vulnerability triggered by a specially crafted IPv6 TCP packet (that firewall A is happy to pass to firewall B), giving the attacker a level of control over Firewall B that allows them to then access the centralised authentication/authorisation system that would have otherwise been off limits to the attacker. The attacker communicates with firewall B using the same accepted protocol that firewall A and firewall B are configured to allow the attacker to access. Firewall B communicates to the authentication/authorisation system using the accepted protocol for doing so. Nothing suspicious appears to be going on unless you look at the patterns of traffic (throughput, duration of connections, number of connections in interval, etc) particularly to the authentication/authorisation system. I don't think in-band attacks on routers, switches, firewalls doing simple ACL checks are a risk worth spending much concern on because parsing IPv4/IPv6/TCP/UDP headers is not hard to securely implement. Riskier architecture would be intrusion detection systems that perform deep packet inspection in-band (e.g. not out-of-band via a beam splitter to a standalone IDS) where there is 1,000,000's of lines of potentially buggy code exposed to attackers. I agree with your point too that a complex network is harder to secure because you need more skill and expertise spread across more people. In such a scenario, it is easier for human mistakes to occur because of the difficulty in communicating, and difficulty in seeing the broader implication of what may appear to be a simple configuration change.
    - vlovich123 5y ago
      In your scenario though, if the company just used firewall B you’d have the same issue. It can’t be less secure. I’m not familiar enough with how enterprise firewalls work to evaluate things from that perspective. I just know operationally, the more moving pieces, the more issues you have to deal with.
      - dhx 5y ago
        The company would be less secure because they would also be wearing the risk that independent of the vulnerability in firewall B, there is potentially also an unknown vulnerability in firewall A being exploited by a different attacker.
- jlgaddis 5y ago
  > Instead of the attacker having to find a vulnerability in a single product, ... ... they must now find at least one vulnerability in each of the firewalls. It's not "pwn firewall A OR B", it's "pwn firewall A AND B".
- wildzzz 5y ago
  Many big companies have what is basically a MITM attack on SSL. They resign everything between you and the network endpoint using an enterprise certificate. It's still encrypted but at some point it's decrypted, inspected, and then re-encrypted. It's mostly seamless but sometimes you have to get a copy of the certificate to add it to things like pip.
  - nobody9999 5y ago
    > Many big companies have what is basically a MITM attack on SSL. They resign everything between you and the network endpoint using an enterprise certificate. It's still encrypted but at some point it's decrypted, inspected, and then re-encrypted. It's mostly seamless but sometimes you have to get a copy of the certificate to add it to things like pip. Yes. And this is a good thing (in an enterprise environment) for a couple of reasons (a few others too, but these should make the point): Proxying connections is inherently more secure than packet filtering/stateful inspection; As was pointed out in another comment[0], most traffic is encrypted these days. Any traffic traversing the enterprise network needs to be visible (unencrypted) to network administrators. This allows them to identify, investigate and, potentially, block suspicious traffic. Any large organization (or even smaller ones with the need and the resources) should be able to decrypt and read every packet traversing their internal network and the ingress/egress points to/from that network. That requires ubiquitous use of proxies for all connections that have an external endpoint. It's likely that some sensitive internal networks/servers/applications should do so as well. While that's very intrusive, it's not your home network, nor is it (semi-)public wifi. It's the wholly owned property (I'm not addressing "cloud-based" resources here -- that's a different long discussion) of that organization. As such, they have every right to read every packet on their network and every byte on their storage. Which is why many organizations have "guest" networks which not only has no access to internal resources, but also only allows connections to external networks and bypasses all the proxies/firewalls as well. This allows employees, contractors and others to maintain their privacy on their own devices without impacting the security of the internal network. Of course, this requires device authentication at the network layer (e.g., 802.1x) to ensure that only authorized devices are permitted access to the internal network. None of the above is particularly new or particularly controversial. [0] https://news.ycombinator.com/item?id=30574794 https://news.ycombinator.com/item?id=30574794
- brobinson 5y ago
  They are describing a setup like this: https://imgur.com/a/R2jbfzj https://imgur.com/a/R2jbfzj
  - waffleiron 5y ago
    When we are implementing this are there diminishing returns on the luck granted by the pfSense firewall? If not, wouldn’t it be better to stack pfSense and rely on luck alone. This would also save us money as we could run them all on the same server in VMs. Sincerely, your customer
  - deleted 5y ago
    [deleted]
  - dhx 5y ago
    In that example network, the Chinese, US, Russian, Israeli and other firewall vendors with their products in series could all have access to the network as each of them has implemented a backdoor that triggers on a hidden condition such as HMAC(secret_backdoor_key, CONCAT(ip.source_address, tcp.source_port, ip.destination_address, tcp.destination_port)) == tcp.sequence_number. Obviously if such a scenario were to play out, a backdoor would be designed to look like a mistaken bug in the software (also making it very hard to detect) rather than the simple example. Fault tolerant architectures such as N-modular redundancy[1] (typically used in the aerospace sector) may provide a more accurate architecture up front. Making protocols much more deterministic and only using nothing-up-my-sleeve numbers would be a good line of investigation. [1] https://en.wikipedia.org/wiki/Triple_modular_redundancy https://en.wikipedia.org/wiki/Triple_modular_redundancy [2] https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number
- SAI_Peregrinus 5y ago
  WRT traffic inspection: if anything other than handshake packets show up unencrypted, it should be able to show an alert.
sandworm101 5y ago
Cool. Defense in depth. But how many vendors/products are now on the table? What will always matter is the most external firewall because once inside that line each subsiquent internal firewall will have a harder time viewing good traffic from bad. And the most inner firewalls between devices inside the home network will have so many holes punched in them to barely be useful. Defense in depth isnt about having multiple layers that repeat the same protections. Defense in depth is about having other layers of non-firewall products to catch the stuff the firewalls miss. If your outside wall is 8' adding more and more 8' walls behind the first does nothing if the army has 9' ladders. You need something different than another wall.
- hcazz 5y ago
  Can you elaborate more on the firewall perspective? Your description makes it sound like for a three tier webapp[0], the entire pdf is suggesting to put a firewall around the presentation layer to limit it to appropriate sources, then the application tier to limit to appropriate sources, then the data tier to appropriate sources, etc. While that should be done, and they are suggesting that, I feel like that's only covering section 2 at best. This doc isn't about adding other similar walls, it's reducing attack surface, limiting blast radius, and encouraging industry standards such as defense in depth, least privilege, and some elements of supply chain security. Your comment suggests you know that, but the PDF states many other things that have nothing to do with firewalls or differentiating good traffic from bad traffic. My take on it is I see this document more as a source to point at internally at the NSA for best practices or a minimum bar to meet, not the best that the industry or the NSA has to offer. Even then, I'd assume that some organization externally will use this to say they aren't "up to the NSAs standards", and push for changes to fix their practices. If it means that more folks learn of common practices in the industry and increase their security as a result, I'm all for folks sharing these practices, whether it's the NSA sharing it or a private organization. [0] - https://www.ibm.com/cloud/learn/three-tier-architecture https://www.ibm.com/cloud/learn/three-tier-architecture
  - sandworm101 5y ago
    I too am all for sharing best practices. I just disagree with some of those practices. Using a mixed bag of a particular product from a variety of vendors sounds great from a management perspective. It seems obvious that one might catch something that another misses. Having a variety of security products watching a network is like how a variety of COVID vaccinations can be better than repeating the same vaccine each time. But more vendors means a greater variety of associated traffic. You end up poking a hole in one firewall so that someone can manage some other firewall. Your IDS sees, and gets used to seeing, all sorts of strange management traffic. Your engineers become complacent, opening up holes upon request by anyone with the correct phone number. There is something to be said for a single strong firewall system from a single vendor. Then you have a single reporting/monitoring system with no shirking of responsibility. That one wall is manned/watched/managed as everyone's first priority. One very tall wall rather than a series of shorter ones. The practice I would promote, but which is rarely ever used outside of defense and/or the biggest companies, is having separate networks for the really important stuff. Why is client data is traveling along the same network as employees streaming netflix? Have one network for general office junk and another physically-distinct network for client data. Why is the office birthday party announcement landing in the same inbox as an email from a "client" requesting a wire transfer? If separating these means some employees have to run two email inboxes or have two computers at their desk, so be it. But doing that costs money. Subscribing to a 3rd or 4th firewall vendor is cheap.
javajosh 5y ago
What, no threat model? I'm really not sure who this is for. If you're actually in charge of network and/or security architecture most of this is too simplistic. But if you're a newbie it leaves out the the most important context (particularly, the threat model) that drives the entire process of securing something. And personally, I'm just not comfortable doing things unless I know why I'm doing it, and that's what the threat model provides.
rapjr9 5y ago
What do you all see as missing from this document? How about the security of apps and of 3rd party update services? Every app that has internet access is a potential vulnerability for the whole network, a direct route to the inside. And we've also seen recently that 3rd party software update services can compromise everything. Are those not considered part of "Network Infrastructure Security"? If you're talking about defense in depth you can't limit the discussion to just the wired network hardware itself because there are all sorts of other things that can compromise the network (insider attacks, BYOD, compromised hardware, phishing, blackmail). You could follow every single step in this document perfectly and your network may still be easily compromised. There's no mention of wireless networks either. Your network could be compromised via an open Bluetooth interface. This also seems like a very Cisco oriented document.
- number6 5y ago
  I am also conflicted trusting an agency that's other job is to make networks less safe when it comes to network safety. The conflict of interest alone if enough, it doesn't even need their track records in spying on everyone.
  - greggsy 5y ago
    I highly doubt any of the content in this is ‘bad’ or misleading - most security people have a pretty good BS detector and it would spread pretty quickly in the community. The worst thing might be a reference to an industry standard protocol, like IPSECv2, which is generally considered secure, but might be broken under certain conditions and only ever exploit under extreme circumstances (to avoid showing their hand).
  - numpad0 5y ago
    > to make networks less safe Could it be substituted by "to get into a network"? Then it could be argued that they need adversaries to establish reliance on a working network.
deleted 5y ago
[deleted]
FourthProtocol 5y ago
I have some experience here, not with the NSA though. BYOD is forbidden, and checked when you enter the building. There is only wired hardware - and wireless is, well, jammed. Any software introduced into such networks is vetted before introduction/deployment. It takes time. 3rd party apps don't auto update - Microsoft for example provide updates that can be vetted before being allowed onto the network. And this is only some bleedingly obvious stuff... The document does not describe SECRET or TOP SECRET environments. Not even RESTRICTED. R, S and TS policies are themselves marked with protective markings, which this PDF lacks. Governments have a lower level of protection called PROTECTED or similar that is closer to what the document describes, but even that would be protectively marked... Looks to me like NSA is sharing some of their lesser sensitive stuff to possibly help their vendors, businesses partners and public at large. Kind of like "we recommend Joe Public do it like so..."
- aborsy 5y ago
  Are there guidelines on how to secure S and TS environments?
  - FourthProtocol 5y ago
    Yes. I assume you're asking if they're publicly available, which is a no. Is not an easy world to penetrate, for good reason.
    - faeyanpiraat 5y ago
      Your website has great structure to communicate your values effectively; it must’ve helped you land some great opportunities.
      - FourthProtocol 5y ago
        Thank you. The only value I set out with when building the more recent version of the site was to share what I know. Too many people learn a thing and keep it to themselves.
jabl 5y ago
Slightly related, is there any analytical writing on the human side of security? How to build organizations that are resistant to intrusion in various forms? From reading books and watching movies as well as applying a bit of common sense, organizations like spy agencies or terrorist networks with more or less independently operating cells work with a strict least-privilege type model such that a mole in one part of the organization doesn't compromise the organization as a whole. And, I'd guess, at least in more formalized organizations, strict logging on who does what etc. All this obviously adds a lot of overhead and friction in communications, which, say, a business operating in a competitive environment can ill afford. I'm quite sure there's no "magic pill", but rather a bunch of choices with tradeoffs (like security vs. ease of cross-team communication I touched on above).
- hashimotonomora 5y ago
  - need to know basis. - strict separation of concerns. - only outbound hiring. - no hiring of people who can be blackmailed. - understand your threat model. - if you were an enemy and had to break into your org, what would you do? Improve that.
based2 5y ago
? - No full static addresses requirement - No double WAF vendors requirements
- detaro 5y ago
  Why would those be particularly important?

130 points by slacka 5y ago

dhx 5y ago

Use of firewalls in series from multiple vendors sounds like a good idea in theory but in practice, does it not make it easier for an attacker to exploit the network? Instead of the attacker having to find a vulnerability in a single product, they can instead find a vulnerability in one of multiple products (a much easier task). Given that every network device communicates with a central authentication/authorisation system, a central logging system and likely central patching, configuration deployment, etc systems, all it takes is to find a vulnerability in one of multiple firewall products, then find a vulnerability in one of the central systems used to mange the network. I'm also perplexed why there is mention of "traffic inspector" and "full-packet capture device" given that almost all traffic traversing a network nowadays is encrypted. Perhaps more useful today would be creating a good understanding of the normal traffic flows so that alarms can be configured for abnormal traffic. For example, perhaps no more than 100 requests to an authentication server occur per device per day. Or patches for a system are no more than 1GB so seeing 1.1GB or more transferred across the management network per day per device would be abnormal.

throwbigdata 5y ago
That’s not how “in series” works.
vlovich123 5y ago
> Instead of the attacker having to find a vulnerability in a single product, they can instead find a vulnerability in one of multiple products (a much easier task) I’m not sure I understand this argument you’re making. If you have them in series then you have to find vulnerabilities for all of them before you can talk to any other system. A vulnerability to one of them only lets you punch through that one layer. In theory of course. I think this advice may not be well flushed out though. For example, if the firewalls are running on the same appliance and have poor isolation/misconfigure settings, an escape in one can bypass the entire set of firewalls (which is maybe what you’re implying?). Having totally isolated firewall machines is inefficient from a capex perspective (more machines than needed for your load) and in general multiple vendors increased your opex costs too (you now need employees that are proficient with multiple vendors which ends up meaning you have teams with dedicated experts per firewall, you have to build automation for multiple vendors with non-standard APIs etc). The bigger problem though is you’ve sacrificed availability which is now divided by N times because every layer you’ve added has to be functioning perfectly or the entire system is down (and if it’s not you’ve implemented this advice incorrectly). I think not mentioning this security/availability/cost trade off is a disservice.
- dhx 5y ago
  The scenario I had in mind is Firewall A and Firewall B are in series and they're different products from two vendors. Firewall B is found to contain a vulnerability triggered by a specially crafted IPv6 TCP packet (that firewall A is happy to pass to firewall B), giving the attacker a level of control over Firewall B that allows them to then access the centralised authentication/authorisation system that would have otherwise been off limits to the attacker. The attacker communicates with firewall B using the same accepted protocol that firewall A and firewall B are configured to allow the attacker to access. Firewall B communicates to the authentication/authorisation system using the accepted protocol for doing so. Nothing suspicious appears to be going on unless you look at the patterns of traffic (throughput, duration of connections, number of connections in interval, etc) particularly to the authentication/authorisation system. I don't think in-band attacks on routers, switches, firewalls doing simple ACL checks are a risk worth spending much concern on because parsing IPv4/IPv6/TCP/UDP headers is not hard to securely implement. Riskier architecture would be intrusion detection systems that perform deep packet inspection in-band (e.g. not out-of-band via a beam splitter to a standalone IDS) where there is 1,000,000's of lines of potentially buggy code exposed to attackers. I agree with your point too that a complex network is harder to secure because you need more skill and expertise spread across more people. In such a scenario, it is easier for human mistakes to occur because of the difficulty in communicating, and difficulty in seeing the broader implication of what may appear to be a simple configuration change.
  - vlovich123 5y ago
    In your scenario though, if the company just used firewall B you’d have the same issue. It can’t be less secure. I’m not familiar enough with how enterprise firewalls work to evaluate things from that perspective. I just know operationally, the more moving pieces, the more issues you have to deal with.
    - dhx 5y ago
      The company would be less secure because they would also be wearing the risk that independent of the vulnerability in firewall B, there is potentially also an unknown vulnerability in firewall A being exploited by a different attacker.
jlgaddis 5y ago
> Instead of the attacker having to find a vulnerability in a single product, ... ... they must now find at least one vulnerability in each of the firewalls. It's not "pwn firewall A OR B", it's "pwn firewall A AND B".
wildzzz 5y ago
Many big companies have what is basically a MITM attack on SSL. They resign everything between you and the network endpoint using an enterprise certificate. It's still encrypted but at some point it's decrypted, inspected, and then re-encrypted. It's mostly seamless but sometimes you have to get a copy of the certificate to add it to things like pip.
- nobody9999 5y ago
  > Many big companies have what is basically a MITM attack on SSL. They resign everything between you and the network endpoint using an enterprise certificate. It's still encrypted but at some point it's decrypted, inspected, and then re-encrypted. It's mostly seamless but sometimes you have to get a copy of the certificate to add it to things like pip. Yes. And this is a good thing (in an enterprise environment) for a couple of reasons (a few others too, but these should make the point): Proxying connections is inherently more secure than packet filtering/stateful inspection; As was pointed out in another comment[0], most traffic is encrypted these days. Any traffic traversing the enterprise network needs to be visible (unencrypted) to network administrators. This allows them to identify, investigate and, potentially, block suspicious traffic. Any large organization (or even smaller ones with the need and the resources) should be able to decrypt and read every packet traversing their internal network and the ingress/egress points to/from that network. That requires ubiquitous use of proxies for all connections that have an external endpoint. It's likely that some sensitive internal networks/servers/applications should do so as well. While that's very intrusive, it's not your home network, nor is it (semi-)public wifi. It's the wholly owned property (I'm not addressing "cloud-based" resources here -- that's a different long discussion) of that organization. As such, they have every right to read every packet on their network and every byte on their storage. Which is why many organizations have "guest" networks which not only has no access to internal resources, but also only allows connections to external networks and bypasses all the proxies/firewalls as well. This allows employees, contractors and others to maintain their privacy on their own devices without impacting the security of the internal network. Of course, this requires device authentication at the network layer (e.g., 802.1x) to ensure that only authorized devices are permitted access to the internal network. None of the above is particularly new or particularly controversial. [0] https://news.ycombinator.com/item?id=30574794 https://news.ycombinator.com/item?id=30574794
brobinson 5y ago
They are describing a setup like this: https://imgur.com/a/R2jbfzj https://imgur.com/a/R2jbfzj
- waffleiron 5y ago
  When we are implementing this are there diminishing returns on the luck granted by the pfSense firewall? If not, wouldn’t it be better to stack pfSense and rely on luck alone. This would also save us money as we could run them all on the same server in VMs. Sincerely, your customer
- deleted 5y ago
  [deleted]
- dhx 5y ago
  In that example network, the Chinese, US, Russian, Israeli and other firewall vendors with their products in series could all have access to the network as each of them has implemented a backdoor that triggers on a hidden condition such as HMAC(secret_backdoor_key, CONCAT(ip.source_address, tcp.source_port, ip.destination_address, tcp.destination_port)) == tcp.sequence_number. Obviously if such a scenario were to play out, a backdoor would be designed to look like a mistaken bug in the software (also making it very hard to detect) rather than the simple example. Fault tolerant architectures such as N-modular redundancy[1] (typically used in the aerospace sector) may provide a more accurate architecture up front. Making protocols much more deterministic and only using nothing-up-my-sleeve numbers would be a good line of investigation. [1] https://en.wikipedia.org/wiki/Triple_modular_redundancy https://en.wikipedia.org/wiki/Triple_modular_redundancy [2] https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number
SAI_Peregrinus 5y ago
WRT traffic inspection: if anything other than handshake packets show up unencrypted, it should be able to show an alert.

sandworm101 5y ago

Cool. Defense in depth. But how many vendors/products are now on the table? What will always matter is the most external firewall because once inside that line each subsiquent internal firewall will have a harder time viewing good traffic from bad. And the most inner firewalls between devices inside the home network will have so many holes punched in them to barely be useful. Defense in depth isnt about having multiple layers that repeat the same protections. Defense in depth is about having other layers of non-firewall products to catch the stuff the firewalls miss. If your outside wall is 8' adding more and more 8' walls behind the first does nothing if the army has 9' ladders. You need something different than another wall.

hcazz 5y ago
Can you elaborate more on the firewall perspective? Your description makes it sound like for a three tier webapp[0], the entire pdf is suggesting to put a firewall around the presentation layer to limit it to appropriate sources, then the application tier to limit to appropriate sources, then the data tier to appropriate sources, etc. While that should be done, and they are suggesting that, I feel like that's only covering section 2 at best. This doc isn't about adding other similar walls, it's reducing attack surface, limiting blast radius, and encouraging industry standards such as defense in depth, least privilege, and some elements of supply chain security. Your comment suggests you know that, but the PDF states many other things that have nothing to do with firewalls or differentiating good traffic from bad traffic. My take on it is I see this document more as a source to point at internally at the NSA for best practices or a minimum bar to meet, not the best that the industry or the NSA has to offer. Even then, I'd assume that some organization externally will use this to say they aren't "up to the NSAs standards", and push for changes to fix their practices. If it means that more folks learn of common practices in the industry and increase their security as a result, I'm all for folks sharing these practices, whether it's the NSA sharing it or a private organization. [0] - https://www.ibm.com/cloud/learn/three-tier-architecture https://www.ibm.com/cloud/learn/three-tier-architecture
- sandworm101 5y ago
  I too am all for sharing best practices. I just disagree with some of those practices. Using a mixed bag of a particular product from a variety of vendors sounds great from a management perspective. It seems obvious that one might catch something that another misses. Having a variety of security products watching a network is like how a variety of COVID vaccinations can be better than repeating the same vaccine each time. But more vendors means a greater variety of associated traffic. You end up poking a hole in one firewall so that someone can manage some other firewall. Your IDS sees, and gets used to seeing, all sorts of strange management traffic. Your engineers become complacent, opening up holes upon request by anyone with the correct phone number. There is something to be said for a single strong firewall system from a single vendor. Then you have a single reporting/monitoring system with no shirking of responsibility. That one wall is manned/watched/managed as everyone's first priority. One very tall wall rather than a series of shorter ones. The practice I would promote, but which is rarely ever used outside of defense and/or the biggest companies, is having separate networks for the really important stuff. Why is client data is traveling along the same network as employees streaming netflix? Have one network for general office junk and another physically-distinct network for client data. Why is the office birthday party announcement landing in the same inbox as an email from a "client" requesting a wire transfer? If separating these means some employees have to run two email inboxes or have two computers at their desk, so be it. But doing that costs money. Subscribing to a 3rd or 4th firewall vendor is cheap.

javajosh 5y ago

What, no threat model? I'm really not sure who this is for. If you're actually in charge of network and/or security architecture most of this is too simplistic. But if you're a newbie it leaves out the the most important context (particularly, the threat model) that drives the entire process of securing something. And personally, I'm just not comfortable doing things unless I know why I'm doing it, and that's what the threat model provides.

rapjr9 5y ago

What do you all see as missing from this document? How about the security of apps and of 3rd party update services? Every app that has internet access is a potential vulnerability for the whole network, a direct route to the inside. And we've also seen recently that 3rd party software update services can compromise everything. Are those not considered part of "Network Infrastructure Security"? If you're talking about defense in depth you can't limit the discussion to just the wired network hardware itself because there are all sorts of other things that can compromise the network (insider attacks, BYOD, compromised hardware, phishing, blackmail). You could follow every single step in this document perfectly and your network may still be easily compromised. There's no mention of wireless networks either. Your network could be compromised via an open Bluetooth interface. This also seems like a very Cisco oriented document.

number6 5y ago
I am also conflicted trusting an agency that's other job is to make networks less safe when it comes to network safety. The conflict of interest alone if enough, it doesn't even need their track records in spying on everyone.
- greggsy 5y ago
  I highly doubt any of the content in this is ‘bad’ or misleading - most security people have a pretty good BS detector and it would spread pretty quickly in the community. The worst thing might be a reference to an industry standard protocol, like IPSECv2, which is generally considered secure, but might be broken under certain conditions and only ever exploit under extreme circumstances (to avoid showing their hand).
- numpad0 5y ago
  > to make networks less safe Could it be substituted by "to get into a network"? Then it could be argued that they need adversaries to establish reliance on a working network.

deleted 5y ago

[deleted]

FourthProtocol 5y ago

I have some experience here, not with the NSA though. BYOD is forbidden, and checked when you enter the building. There is only wired hardware - and wireless is, well, jammed. Any software introduced into such networks is vetted before introduction/deployment. It takes time. 3rd party apps don't auto update - Microsoft for example provide updates that can be vetted before being allowed onto the network. And this is only some bleedingly obvious stuff... The document does not describe SECRET or TOP SECRET environments. Not even RESTRICTED. R, S and TS policies are themselves marked with protective markings, which this PDF lacks. Governments have a lower level of protection called PROTECTED or similar that is closer to what the document describes, but even that would be protectively marked... Looks to me like NSA is sharing some of their lesser sensitive stuff to possibly help their vendors, businesses partners and public at large. Kind of like "we recommend Joe Public do it like so..."

aborsy 5y ago
Are there guidelines on how to secure S and TS environments?
- FourthProtocol 5y ago
  Yes. I assume you're asking if they're publicly available, which is a no. Is not an easy world to penetrate, for good reason.
  - faeyanpiraat 5y ago
    Your website has great structure to communicate your values effectively; it must’ve helped you land some great opportunities.
    - FourthProtocol 5y ago
      Thank you. The only value I set out with when building the more recent version of the site was to share what I know. Too many people learn a thing and keep it to themselves.

jabl 5y ago

Slightly related, is there any analytical writing on the human side of security? How to build organizations that are resistant to intrusion in various forms? From reading books and watching movies as well as applying a bit of common sense, organizations like spy agencies or terrorist networks with more or less independently operating cells work with a strict least-privilege type model such that a mole in one part of the organization doesn't compromise the organization as a whole. And, I'd guess, at least in more formalized organizations, strict logging on who does what etc. All this obviously adds a lot of overhead and friction in communications, which, say, a business operating in a competitive environment can ill afford. I'm quite sure there's no "magic pill", but rather a bunch of choices with tradeoffs (like security vs. ease of cross-team communication I touched on above).

hashimotonomora 5y ago
- need to know basis. - strict separation of concerns. - only outbound hiring. - no hiring of people who can be blackmailed. - understand your threat model. - if you were an enemy and had to break into your org, what would you do? Improve that.

based2 5y ago

? - No full static addresses requirement - No double WAF vendors requirements

detaro 5y ago
Why would those be particularly important?