Firewall Rules Change Request Form
Please read the procedure at the end before hand in the request
To: IT Security Services, BCY 7 (Email: ITSS)
Date:
Our reference (ITSS Use Only):
Part A: Request Details (To be completed by requestor)
* Name of Requestor:
* Location:
* Requested Date:
*Name of Supervisor:
* Staff Number:
* Business Unit / Branch:
* Approval List:
* Supervisor Contact No.:
* Contact Phone No.:
* Implementation Date: _____________________
* Brief description on the policy change request:
.
Part B: Firewall Rules Details (To be completed by requestor)
Rule *1Action
#
(D/I)
IP
* Source
Hostname
Description
IP
* Destination
Hostname
* Description
* Service/
Protocol†
* Sensitive * Duration of
Data
use
Involved?
(Y/N)^
* Project
name
1
Action: D=Delete, I=Insert
* Field marked in RED: Mandatory field
† Except for HTTP / HTTPS, system owner’s approval is required.
^ If the answer is Y, provide further information in table ‘Sensitive Data Details’. For the fields that are not filled out correctly, ITSS team may reject the request.
IT Security Service (Confidential)
Last updated on 5 Nov, 2009
Page 1 of 7
FMITS39.DOC
Issue: 1.0 Revision 5
Sensitive Data Details
Rule #
If the system contains sensitive data (Information Security
Baseline 6-3 to 6-6, p.133 to135, what is the security
classification of the data being handled by this server/
application? Please refer to the definition of data classification
in the Information Security Baseline to answer this question.
(Strictly confidential, Confidential, Internal use only and
Public Information)
What information does the data contain? For example: HK ID number,
salary information, client names, addresses and/ or credit card
information, etc.
Does the application interface with other
existing application/ system? If so, please list it
out and describe the reason or justification of
the application interface below.
Other requirements (e.g. routing)
IT Security Service (Confidential)
Last updated on 5 Nov, 2009
Page 2 of 7
FMITS39.DOC
Issue: 1.0 Revision 5
Part C: Address Translation Rules Details (To be completed by requestor)
Rule #
2
Action
(D/I)
IP
Source
Hostname
Translated IP
IP
Destination
Hostname
Translated IP
Comments
Part D: Verification Test Details (To be completed by requestor)
* Verification Test Contact Person:
* Contact No.:
Verification Steps:
1
2
3
4
Part E: Additional information checklist
Tick  the following box if you have the following information ready and passed to ITSS for audit purpose.
 Result of tracert (Window XP or Vista) and traceroute (Unix) from source address to destination address
 Completed RFS for new JV projects
 Associated network diagram
Request for File or Database Service
Service Information
1. Usage Description
2. Data Sensitivity
3. Data Size
4. Frequency of Data Transferring
Remark
2
Action: D=Delete, I=Insert
* Field marked in RED: Mandatory field
IT Security Service (Confidential)
Last updated on 5 Nov, 2009
Page 3 of 7
FMITS39.DOC
Issue: 1.0 Revision 5
Part F: Verification (To be completed by ITSS)
Section 1 – To be completed by implementator
Firewall Name:
Implemented By:
Section 2 – To be completed by verifier
Verified By:
Section 2.1 – Firewall Rule Change Request
Description:
Review by ITSS Operation Team Leader
from GDCN
View FW Log after the change to see if
there is any abnormal traffic logged
VT by application support/user
Check corresponding Sitescope
monitoring items
Others:
Remarks:
Section 2.2 –Routing Change
Description:
Check routing after change
Check start up script to ensure new
routing is updated in startup script
Ping the destination
Traceroute the destination
VT by application support/user
Others:
Remarks:
Section 2.3 – Network Interface Change
Description:
Check interface up/down
Ping interface
Ping gateway
Check startup script to ensure new
interface is updated in startup script
Completion Time:
Verification Time:
Test Procedure
Review the FW Rule Request
Expected Result
RW Rule is compiled to security policy
Open Log viewer to check the FW log
No abnormal traffic logged
Test accepted (Y/N)?
VT by application support/ user
VT OK
Connect to Sitescope and see if there are any alarmsMonitoring
after
status normal
FW rule change
Test Procedure
`route get <dst ip> ` to check the gateway
`cat /etc/rc3.d/S15routes` to check if the
corresponding route exists
`ping <dst ip>`
`traceroute <dst ip>`
VT by application support/user
Expected Result
Gateway is correct
Route exists and correct
Test Procedure
`ifconfig –a` to check the interface status
`ping <interface ip>`
`ping <gateway ip>`
`cat /etc/hosts`
Expected Result
Interface is up
The ping result is normal
The ping result is normal
IP and hostname are updated in hosts file
`ls –l /etc/hostname.*`
Interface file is created in /etc directory
`cat /etc/netmasks`
Netmask is correct
Test accepted (Y/N)?
The ping result is normal
The path is going through as expected
VT OK
Test accepted (Y/N)?
Others:
Remarks:
IT Security Service (Confidential)
Last updated on 5 Nov, 2009
Page 4 of 7
FMITS39.DOC
Issue: 1.0 Revision 5
Section 2.4 – Miscellaneous Change (to be completed by Change Implementator)
Description:
Test Procedure
Change Item 1:
Expected Result
Test accepted (Y/N)?
Sign by Implementator:
Sign by Verifier:
Change Item 2:
IT Security Service (Confidential)
Last updated on 5 Nov, 2009
Page 5 of 7
FMITS39.DOC
Issue: 1.0 Revision 5
Procedure for Firewall Policy Update Request
1. Fill in the change information in FMITS39.doc; all mandatory fields (marked as RED) must be filled in.
2. Send the completed fmits39.doc to mail address "ITSS", together with
- result of tracert (Window XP or Vista) and traceroute (Unix) from source address to destination address
- for each FTP service, provide the information: I. Usage, II. Bandwidth will be used (e.g. 8KB), III. Usage frequency (e.g. once a week) and IV. Sensitivity level
of the data (e.g. password with encryption - low sensitive)
- associated network diagram (if requested by ITSS)
- approval of associated project/team manager
- completed RFS form for new JV projects
3. The request must be sent to ITSS for verification three working days before the change.
4. Incompletion of the request form, especially the mandatory fields, will cause the request to be rejected.
5. Regular change on firewall policy will be done every Thursday 1800 - 2300. If Thursday is a public holiday, the firewall rule change will be executed on the next
working day.
6. Request with all related (mandatory) information required which is submitted to ITSS less than three working days before the change will be considered in the next
change schedule. If ITSS requests to obtain additional information, the requester should send it to ITSS COB Wednesday (the working day before schedule change
day). Otherwise, the request will be postponed to next change schedule.
7. ITSS will inform the VT Contact to perform the verification test after the implementation. The firewall rules implementation will be fallback if the VT Contact
/requestor/supervisor cannot be reached or ITSS cannot obtain a confirmation on the implementation result.
8. Simple problem will be fixed immediately. Complicated problem might not be fixed right away and if this is the case, the change will be fallback and revised in the
next change schedule.
9. Request may be rejected or fallback if







Mandatory and/or requested information has not been provided
Mandatory field is blank and/or not correct
Detail traceroute/tracert information is invalid or has not been sent to ITSS
VT is not performed by the requestor/its representative right after the change
The request does not comply with security standards
The request is not approved by ITSS manager/supervisor
Incomplete RFS form for JV projects
10. The rejected request will be noticed one working day before the implementation.
Example for Part B:
Rule Action
#
(D/I)
IP
Source
Hostname
Description
IP
Destination
Hostname
Description
Service/
protocol
Sensitive Data Duration Project name
Involved (Y/N) of use
1
2
I
I
136.136.131.80
10.21.22.101
RS53
mywks1
MNP DR Machine
Project A Workstation
10.8.32.9
192.168.21.21
Host01
Host A
Testing DR
Testing Host A
FTP
telnet
Y
Y
3
D
10.21.22.110
old mywks1
Project A workstation
192.168.21.21
Host A
Testing Host A
telnet
Y
ongoing
until end of
May, 2000
MNP
ABC
ABC
Sensitive Data Details:
IT Security Service (Confidential)
Last updated on 5 Nov, 2009
Page 6 of 7
FMITS39.DOC
Issue: 1.0 Revision 5
Rule #
If the system contains sensitive data, what is the security
classification of the data being handled by this server/
application? Please refer to the definition of data classification
in the Information Security Baseline to answer this question.
(Strictly confidential, Confidential, Internal use only and
Public Information)
What information does the data contain? For example: HK ID number,
salary information, client names, addresses and/ or credit card
information, etc.
Does the application interface with other
existing application/ system? If so, please list it
out and describe the reason or justification of
the application interface below.
1
2
Internal use
Confidential
Yes, BOM
Yes, Dragon
3
Strictly Confidential
Names and billing figures
User names, addresses, Hong Kong ID numbers and salary
information.
Credit card information, user bank account numbers, banking
information and passport/ Hong Kong ID numbers.
IT Security Service (Confidential)
Last updated on 5 Nov, 2009
Page 7 of 7
Yes, LIS
FMITS39.DOC
Issue: 1.0 Revision 5