Tag Archives: scope of work

Template Scope of Work: Juniper SRX Consultancy – CESG Certified VPN

juniper

Juniper SRX Consultancy – CESG Certified VPN

  1. Day 1 – Installation of 2 x Juniper SRX100 firewalls
  2. Day 2 – Configure Certificate based User VPN to SRX firewalls
  3. Day 3 – Continue configure & testing Certificate based User VPN to SRX firewalls
  4. Day 4 – Documentation based on CESG guidelines
  5. Day 5 – Follow up remediation work required as a result of the NCC or other third-party testing and validation

Caveats, Requirements, Assumptions

  1. SRX100 – Firewalls to be configured with VRRP for failover, but each firewall will be standalone. They will NOT be configured as a cluster with stateful failover (to meet CESG security requirements).
  2. SRX100 – Initial firewall configuration assumed to be  a basic configuration based on estimated 1 day installation
  3. SRX100 – Full admin & user access to firewalls at all times to test
  4. IPSec VPN – Configuration of client to firewall IPSec VPN’s. IPSec tunnel will be authenticated using x.509 certificates (using Windows 7 IPSec client with certs manually deployed).
  5. IPSec VPN must be configured as per CESG security guidelines (http://www.cesg.gov.uk/servicecatalogue/CPA/Pages/CPA-certified-products.aspx)
  6. IPSec VPN fully documented as to where it meets, and does not meet the requirements. This document is a key deliverable and will be submitted to the MoD as part of their compliance submission.
  7. IPSEC VPN using Windows 7 clients with IPSec tunnel (cert based) to the firewalls, IPSEC VPN Users user will authenticate via RSA 2FA using RSA Authentication Manager V8.1 for user authentication
  8. IPSEC VPN – configuration to be done on best endeavours basis – based on any caveats/constraints from Microsoft & Juniper Networks
  9. IPSEC VPN – Microsoft Certificate or other CA server to be in place and configured with User certificate issued.
  10. RSA Solution: Reseller will be installing the RSA solution.
  11. RSA solution: Integration details to be provided
  12. IPSEC VPN – after authentication users will be able to launch a MS Terminal Services desktop session.
  13. Consultant – Power for consultants laptop to be available in data centre
  14. Consultant – Internet Access in data centre
  15. Consultant – serial & network access to firewalls
  16. Consultant – responsible for Juniper SRX configuration only
  17. Documentation – exact documents to be followed to be given to consultant
  18. Documentation – to be produced in simple format covering main technical issues with formatting & other presentation as time allows.
  19. Equipment – Surrounding network already configured to allow routing between firewall, outside network &  MS Terminal Services and MS Certificate servers
  20. Testing – customer to provide laptop to test.
  21. Follow up work will be done as time allows and will be assumed to consist of minor changes to configuration & documentation
  22. Remediation Work – undertaken after third party testing has been performed.

Template: 4 Days Check Point to Juniper Firewalls Migration

juniper

4 Days Juniper Firewalls Consultancy

 Scope of work

  • Install 2x Juniper SSG320M in first site
  • Replace existing Check Point firewalls with Juniper appliances
  • Install 1x Juniper SSG320M in second site
  • Configure VPN between sites
  • Configure for Remote Access with NCP client

Time

  • Days 1 & 2– Configure Appliances ready for initial deployment
  • Day 3 – Complete Configuration of  Appliances & deploy to sites
  • Day 4 – Configure for Remote Access with NCP client

 Caveats

Initial Build

  • Full access to SSG320M Firewalls
  • Access to view current Check Point Configuration
    • Network configuration
    • Firewall policies
    • NAT rules
    • VPN setup
  • Build Environment to be available to configure Juniper appliances
  • Juniper Configuration to mimic Check Point configuration
  • Preshared key VPN to be configured between sites

Live deployment

  • Downtime required to deploy Juniper devices
  • Access to both firewalls required when deploying appliances (either remote or local access)
  • Surrounding switches/routers ARP tables may need clearing when deploying Juniper in place of previous Check Point appliances – either by:
    • CLI Access
    • reboot

Remote Access

  • Customer to have purchased NCP Secure Client – Juniper Edition
  • Customer device available to configure & test VPN connection
  • If Certificate based User Authentication required:
    • Certificate Authority to be already configured to issue certificates to Remote access users
    • Certificates to be issued to User Devices

Outside Scope

  • Any Other work outside of scope

 

Template: RSA Authentication Manager 8.1 Installation with RBA

RSA Token
Risk Based Authentication

Consultancy

3 Days RSA Authentication Manager Consultancy – version 8.1 with Risk Based Authentication

Scope of Work

  • Installation of Primary RSA Authentication Manager version 8.1 Appliance on to an ESXi 4.x/5.x Environment
  • Installation of Replica RSA Authentication Manager version 8.1 Appliance on to an ESXi 4.x/5.x Environment
  • Integrate RSA with Active Directory
  • Configure RSA for Webtier Configuration
  • Installation of web Tier Components
  • Integrate Netscaler Virtual server to Load Balance Web Tier Servers
  • Integrate Netscaler Access Gateway to provide Risk Based Authentication
  • Provide skills transfer

 

Timeline

  • Day 1 – BACK END
  1. Initial build of Primary & Replica RSA version 8 servers on VMWare
  2. Configure Replication between RSA version 8 Servers
  3. Integration to Active Directory
  4. Configure RSA servers ready for web tier integration
  • Day 2 – FRONT END
  1. Install web tier components
  2. Configure Netscaler as a Load Balancer for webtier
  3. Configure Netscaler for Risk Based Authentication
  • Day 3 – TESTING
  1. Test web tier components & external authentication
  2. Admin Console Configuration
  3. Skills Transfer to admin staff
  4. Documentation

Caveats

 VMWare ESXi Requirements
  • Full access to VMware Vsphere client to access suitable ESXi 4.x/5.x host or VCenter Server Consoles in order to install setup RSA OVA File.
  • Installation of Primary RSA Authentication Manager version 8.1 already installed  by customer onto an ESXi 4.x/5.x Environment
  • Installation of Replica RSA Authentication Manager version 8.1 already installed  by customer onto an ESXi 4.x/5.x Environment
  • ESXi host to meet minimum requirements: 100 GB (Thick-provisioned storage when deploying the virtual appliance), 4 GB of memory (preferably 8GB RAM), At least one virtual CPU. Note: By default, each Authentication Manager instance is deployed with 8 GB of memory and two virtual CPUs.
  • Customer is responsible for VMware host environment and any tasks related to changes on VMware.
  • The virtual appliance only supports the E1000 virtual network adapter. Do not change the default network adapter or add a new virtual network adapter to the virtual appliance.
  • For additional hardware requirements for the physical server hosting the virtual appliances, see your VMware documentation.
  • VMware snapshots may be required at various stages in deployment – adequate disk space must be available to do this.
RSA Installation
  • Customer to supply RSA version 8.1 Software & licenses
  • License file may need to be downloaded from RSA Download Central at https://download.rsasecurity.com if not already obtained
  • Use the credentials and the license serial number that RSA e-mailed to you to log on to the site and download the license file. If you did not receive an e-mail with the logon credentials, contact the RSA Exceptions (support) Desk by sending an e-mail with your contact information and license serial number (provided in your order confirmation) to support@rsa.com or contacting 01344 781100
  • Further details on the process are available in a 5 min youtube video here: http://www.youtube.com/watch?v=5e9tawZ8JfU
  • The location of the license file before running the appliance Quick Setup Process
  • The network information for each appliance must be provided: the fully qualified domain name (FQDN), static IP address, subnet mask, default gateway, and DNS server IP addresses
  • RSA Servers will need fully qualified Hostnames configured in DNS (forward & reverse lookups)
  • RSA servers will need to be synced to an NTP time source – it is assumed that this is the same time source as previous installation – differences in time can impact user authentications
  • Any Firewalls must be configured to allow all RSA & other components to communicate with one another
    • TCP 7004 & 7072 Ports required for Administration Consoles – these must be allowed through Firewalls from wherever administration performed on network
    • TCP 7002, 1812 & 1813 Ports are required for Replication  – these must be allowed through Firewalls for replication to work
Web tier & Citrix Netscaler Load Balancer
  • 2 web tier servers will be built
  • Minimum Requirements for Web Tier Servers: Hard drive: 2 GB for web tier installation, 4 GB-20 GB free space for logs and updated component downloads. RAM: 2 GB.
  • External Firewall Requirements: The following ports are required through the firewall: 443 HTTPS (TCP), DMZ: 443 HTTPS (TCP), Internal Firewall: 7022 T3S (TCP)
  • Operating System Requirements: Red Hat Enterprise Linux 5/6 Server (64-bit) or Windows Server 2008 R2 (64-bit)
  • Web Tier will be built with a Netscaler  load balancer as recommended for use with Risk Based Authentication
  • 2 Individual public web-tier hostnames and a shared virtual hostname must be provided and be addressable from the public side of the web tier.
  • The Netscaler load balancer must meet the following requirements:
    • User persistence. The load balancer must send a client to the same server repeatedly during a session. The load balancer must send the client to the same Authentication Manager instance or web-tier server, depending on your deployment scenario, during an authentication session.
    • X-Forwarded-For headers. Load balancers in the application layer cause all requests to appear to come from the load balancer. You must configure load balancers to send the original client IP address in the “X-Forwarded-For” header. This is the default for most application layer load balancers.
    • HTTPS Redirection. The load balancer must be able to redirect HTTPS requests to another URL. This allows users to use the load balancer hostname to access the Self-Service Console.
  • The web tier must be accessible by HTTPS from the public side of the web tier. Certificates will be needed for the servers.
  • The web tier must be able to communicate with the RSA servers over port TCP 7022 – this port must be open through any firewalls.
  •  The date and time on the web-tier server match the date and time on the instance with which the web tier will be associated (primary or replica) within one minute.
  • An administrator account must be used during installation

Citrix Netscaler Risk Based Authentication Integration

  • Integration with Citrix Netscaler will be configured based on supported configuration as determined by documentation at https://gallery.emc.com/servlet/JiveServlet/download/1609-25-4730/Citrix_NetScalerGateway10.1_AuthMan8.0.pdf
  • The Netscaler versions should be as listed in the guide above. The version supported is version 10.1 – other versions may work and will be done on a best endeavours basis.
  • The Netscaler will require a script to be uploaded to the device
  • Customer is responsible for any integrated 3rd party products.
  • Note: In order for Risk Based Authentication to work – the Responder feature must be licensed on the Netscaler gateway
  • LDAP configuration details will be required to configure integration with Active Directory – a System Admin Account must be provided for communication.
Active Directory
  • Current Active directory support is for Microsoft Active Directory 2008 R2 (other versions may work but will be unsupported by RSA)
Post Implementation
  • Basic Skills transfer as time allows to Admin staff
Outside Scope
  • Software & Hardware Tokens
  • Trusted Realm Deployments
  • Documentation – Basic screenshots of installation process can be done as time allows if required
  • Any other RSAconsultancy requirements and RSA features not discussed in scope of work & caveats are outside agreed scope of consultancy – and may be done as time allows

 

Template: RSA Authentication Manager 6.1 to 8.1 Consultancy

RSA Token

Scope of Work

4 Days RSA Authentication Manager Consultancy – Migration from version 6 to version 7.1 Appliance

Day 3 may require out of hours – so might be a Thur/Fri/Sat/Mon

  • Installation of Primary RSA Authentication Manager version 8.1 Appliance
  • Installation of Replica RSA Authentication Manager version 8.1 Appliance
  • Integrate RSA with Active Directory
    • Migrate Data from existing 6.1 Software to new version 8.1 Appliance
    • Confirm migration by testing access
    • Complete any other configuration changes for new system (based on similar features that were used in version 6 – Admin Roles etc)
    • Document the build of the solution
    • Provide Basic skills transfer

Caveats

Suggested Timeline

  1. Day 1 –
    1. Initial build of Primary & Replica RSA version 8.1 server – no configuration
    2. Start Build Documentation
    3. Configuration of Primary RSA version 8.1 Appliance with integration to Active Directory
    4. Continue Build Documentation – AD Integration
    5. Test Migration
    6. Day 2 –
      1. Configure Replication between RSA version 8.1 Servers
      2. Basic Skills Transfer to admin staff
      3. Continue Build Documentation – RSA Replica Integration
    7. Day 3 –
      1. Migrate Primary RSA – from version 6.1 to version 8.1
      2. Test
      3. Migrate Replica RSA – from version 6.1 to version 8.1
      4. Test
    8. Day 4 –
      1. Complete any other configuration changes for new system – Role Based Admin setup etc
      2. Finalize Build Documentation
      3. Final Skills Transfer

RSA Installation

  1. RSA version 8.1 will be installed on to new IP addresses initially and then changed to existing version 6 IP addresses once version 6 is powered off. Hostnames will remain unchanged.
  2. Customer to supply RSA version 8.1 Appliances, Tokens, token seed Files & licenses
  3. License file may need to be downloaded from RSA Download Central at https://download.rsasecurity.com if not already obtained
  4. Use the credentials and the license serial number that RSA e-mailed to you to log on to the site and download the license file. If you did not receive an e-mail with the logon credentials, contact the Exceptions Desk by sending an e-mail with your contact information and license serial number (provided in your order confirmation) to support@rsa.com
  5. The location of the license file is needed before running the appliance Quick Setup Process
  6. The License File must support the number of tokens & users with fixed passwords added/migrated to the system
  7. The network information for each appliance must be provided: the fully qualified domain name (FQDN), static IP address, subnet mask, default gateway, and DNS server IP addresses
  8. RSA Servers will need fully qualified Hostnames configured in DNS
  9. RSA servers will need to be synced to an NTP time source
  10. Any Firewalls must be configured to allow all RSA & other components to communicate with one another
  11. It is recommended that a test Agent is installed to Windows PC to test Authentication of system prior to migration of 6.1 Data
  12. Initial RSA Admin Password used on system to be specified by customer –Password provided will be used in super, operations console, radius & master password unless otherwise specified. If this needs to be changed at a later date – procedures are within the documentation.

Third Party Product integration

  1. Any Integration with 3rd party products will be configured based on supported configuration as determined by documentation at https://www.rsasecured.com
  2. With regard to above – existing products should migrate across to new system without any changes on existing systems – above procedures will only be applied where migration of a particular agent has not successfully migrated – yet all other agents have. In the case where no of agents migrate – system will be reverted back to existing version 6.1
  3. Customer is responsible for 3rd party products and other components.
  4. LDAP configuration details will be required to configure integration with Active Directory – a System Admin Account must be provided for communication.
  5. Current Active directory support is for Microsoft Active Directory 2008 R2
  6. As RSA servers will retain IP addresses of existing units – ARP tables may need to be cleared of surrounding equipment (if this doesn’t happen automatically) so that traffic can be redirected to new MAC addresses of new servers.

Migration of 6.1 Data

  1. Full connectivity to 6.1 Installed RSA systems (RDP or direct connection)
  2. Downtime to stop Primary RSA 6.1 Server to take database dump files
  3. 2 migrations to be performed –
    1. initial test migration on day 1 with dumped data taken from live 6.1 RSA primary server and imported to check for any issues with import. A Report can also be run that highlights any potential issues with migration – system will be reverted after this migration to a clean VMware snapshot to continue with build of server ready for final migration
    2. final migration – downtime needed of RSA 6.1 Primary Server after this stage initiated
    3. Once 6.1 primary server is stopped and data copied off during final migration – 6.1 server will be powered off. Version 8.1 Primary server will have IP Address changed to that of existing system.
    4. Ability to copy dump files & other required files between 6.1 & 8.1
    5. Migration of data is assumed to be migration of agents, user accounts, tokens, PINS and associated user data only – other configuration may require manual setup post migration.
    6. Confirmed testing to new version 8 server – will confirm successful migration of data and continuation of below steps.
    7. Downtime to stop Replica RSA 6.1 Server to take database dump delta records
    8. Once 6.1 primary server is stopped and data copied off – 6.1 server will be powered off. Version 8.1 Replica server will have IP Address changed to that of existing system.
    9. Ability to copy dump files & other required files between 6.1 & 8.1
    10. Confirmed testing to new version 8.1 replica server – will confirm successful migration of data

Outside Scope

  1. Self-Service Console is assumed to be for admin use only.
  2. On Demand Authentication is outside of scope
  3. Provisioning component of Self service is outside of scope
  4. Trusted Realm Deployments are outside of scope
  5. Any other RSA consultancy requirements and RSA features not discussed in scope of work & caveats are outside agreed scope of consultancy.

Documentation

  1. Documentation of build of system will be provided- other documentation is outside of scope

Skills Transfer

  1. Basic Skills transfer will be given as time allows to admin staff using system after initial build and prior to migration.
  2. Another basic skills transfer can be given post migration to admin staff using system
  3. Skills transfer will cover basic admin tasks and how system built.