Click here to load reader

Deployment of IPSec VPN VPN, IPSec, PKI, Smart Cards

  • View
    34

  • Download
    6

Embed Size (px)

DESCRIPTION

Ivan Svoboda Manager Information security projects. Deployment of IPSec VPN VPN, IPSec, PKI, Smart Cards. Agenda. Business drivers VPN levels VPN & Firewall VPN & PKI VPN & Security Certification. Current issues. E-commerce, E-government Internet services Flexibility - PowerPoint PPT Presentation

Text of Deployment of IPSec VPN VPN, IPSec, PKI, Smart Cards

Metody analýzy rizikIvan Svoboda
*
IPSec compatibility: ICSA certification
Each component in the network solves its own distinct problem
Issues: Performance, reliability, policy integration, TCO, …
Security: question of protected area perimeter
You can deploy a VPN service with or without a firewall. Each component solves its own distinct problem.
Think of your network as a house and the firewall as your guard dog. The dog protects all of your valuables that are in the house. But what happens if you want to take your priceless jewels to a jewelry store for appraisal. You need an armored car for protection. Think of your VPN as that armored car. It protects all your confidential data as it travels across the public network. Just as the armored car protects the jewels as they travel to the jewelry store.
In some case you need both a firewall and a VPN device while in others you will need only a VPN device. The TimeStep solution is complimentary to firewall technology.
*
VPN Gateway authenticates users with X.509 certificates
If all traffic is encrypted VPN Gateway acts as “perfect” firewall
No other filtering
Secure VPN Gateway
Head office LAN
The Newbridge 230 series can be deployed without a firewall if your VPN is merely an extension of your private network and you have no requirements for additional firewalling.
Because it authenticates all traffic through X.509 certificates, only known users are allowed to pass the secure VPN gateway. In this scenario, the Newbridge Secure VPN gateway acts as a “perfect” firewall by blocking all traffic that is unauthenticated. Thus, network access will be validated and secured by the VPN system. It can also perform additional packet filtering to restrict users to certain hosts.
*
Firewall can perform additional packet filtering, authentication, and application proxies
No changes to firewall security policy
Security perimeter ?
Access router
If the 230 series is deployed outside the firewall then:
All VPN traffic is decrypted just outside the firewall by the secure VPN gateway , allowing the firewall to perform any additional authentication and application proxies before the data contacts the internal network.
*
Network access validated and secured by VPN system
Security policy more flexible and simple to implement
No network traffic bottlenecks
Secure VPN Gateway
If the 230 series is deployed in parallel to the firewall then:
The 230 series acts as a second point of access to the corporate network. The secure VPN gateway will act as a “perfect” firewall, blocking all unauthenticated traffic. Because it authenticates all traffic through X.509 certificates, only known users are allowed to pass the Newbridge 230 series.
This solution allows the firewall to maintain its present security policy or to implement a more severe policy, because it will not be required to allow any valid users to access the network. Network access will be validated and secured by the VPN system.
Using this method, security policy is more simple to implement. Remote access to the network (VPN) and access to network resources – such as HTTP servers -- by those who are not valid users are different security problems. By using both a VPN system and a firewall system in parallel, these different problems can be handled with different security policies. Attempting to integrate the two makes security far more complex.
*
WAN
VPN
router
FW
VPN
DMZ
WAN
VPN
router
FW
VPN
DMZ
Protected area
Transport ISAKMP / IKE (UDP/port500)
Network address translation (NAT)
*
Secure VPNs and Authentication
Two ends wishing to set up a secured session need to know who they are communicating with, otherwise…
spoofing attack
man-in-the-middle attacks
The secure tunnel needs to be authenticated at both ends
Authentication options (IKE):
Shared secret
So far IPSec has set up the secure VPN. This ensures the confidentiality and integrity of the data. However, all VPNs must be authenticated or there exists the possibility of some attacks.
*
User enters a password for authentication
supported by IKE, in lieu of certificates
longer passwords are more secure
password never traverses the network
But…not as scalable as certificates
password administration becomes difficult
We’ve talked a lot about certificates. They are very scalable, good for larger enterprises, and they are very transparent to the user. The user does not see a lot of the transactions that are happening. But, if you have a very small set up, or if you are only setting up one branch office to another, a certificate infrastructure may be too expensive for you, or be more administrative headaches than you want.
An alternate option to authentication, is shared secret. This is a password. The user would be given a password to type in when they are dialing in from outside the network. That password would let you in.
In the past, we exchanged certificates to authenticate the user. In this case, the gateway would send a message back asking for the password. If the user gives the right password, it lets them in.
But, as I mentioned, this is not as scalable as certificates. If you only have to tell one person, one password, that’s easy. But, if you have to tell one password to ten different people, it’s getting a bit tedious. And if they each have different passwords, then I have to keep ten different passwords for ten different people. And if we start to increase it, it becomes quite a headache.
In this case, certificates become the better option.
Identity
IP
Password
VPN is a “killer” aplication for PKI
Dynamic modifications:
Pouze strun. Detaily jsou na následujících stránkách.
*
User B
User C
Inventory subnet
This is what I meant when I mentioned secure VPN groups.
What we have hear is a bunch a different groups. These are three users that are talking to the same network. Within the network is a segment with a engineer subnet, a finance subnet, and a inventory subnet. For different reasons you may not want certain people having access to the information in the subnet. If a subnet were HR, it would be obvious that you would not want a user to have access to personnel files, but in other cases, there might not just be a need.
In this case, user A needs access to the engineering subnet, so he/she is part of the engineering VPN group.
The finance VPN group includes finance people. A finance user who travels has access to the finance subnet. They do not have access to the engineering subnet.
However, we have an inventory subnet. This could be accessible by an operations person but finance needs that information as well. In this case, user B is part of the inventory subnet as well as the finance subnet.
*
Private key operations (electronic signature on-card)
Security !
*
Single smart card
*
CR: Electronic Signature Act Regulation
Requirements for the private key protection, as a part of secure signature creation device)
Levels 1-4
Level 2:
User authentication
VPN, PKI, smart card, …
*
Security certifications

Search related