Monday, January 13, 2020

Linux Software RAID

Introduction

The main goals of using redundant arrays of inexpensive disks (RAID) are to improve disk data performance and provide data redundancy.
RAID can be handled either by the operating system software or it may be implemented via a purpose built RAID disk controller card without having to configure the operating system at all. This chapter will explain how to configure the software RAID schemes supported by RedHat/Fedora Linux.
For the sake of simplicity, the chapter focuses on using RAID for partitions that include neither the /boot or the root (/) filesystems.

RAID Types

Whether hardware- or software-based, RAID can be configured using a variety of standards. Take a look at the most popular.

Linear Mode RAID

In the Linear RAID, the RAID controller views the RAID set as a chain of disks. Data is written to the next device in the chain only after the previous one is filled.
The aim of Linear RAID is to accommodate large filesystems spread over multiple devices with no data redundancy. A drive failure will corrupt your data.
Linear mode RAID is not supported by Fedora Linux.

RAID 0

With RAID 0, the RAID controller tries to evenly distribute data across all disks in the RAID set.
Envision a disk as if it were a plate, and think of the data as a cake. You have four cakes- chocolate, vanilla, cherry and strawberry-and four plates. The initialization process of RAID 0, divides the cakes and distributes the slices across all the plates. The RAID 0 drivers make the operating system feel that the cakes are intact and placed on one large plate. For example, four 9GB hard disks configured in a RAID 0 set are seen by the operating system to be one 36GB disk.
Like Linear RAID, RAID 0 aims to accommodate large filesystems spread over multiple devices with no data redundancy. The advantage of RAID 0 is data access speed. A file that is spread over four disks can be read four times as fast. You should also be aware that RAID 0 is often called striping.
RAID 0 can accommodate disks of unequal sizes. When RAID runs out of striping space on the smallest device, it then continues the striping using the available space on the remaining drives. When this occurs, the data access speed is lower for this portion of data, because the total number of RAID drives available is reduced. For this reason, RAID 0 is best used with drives of equal size.
RAID 0 is supported by Fedora Linux. Figure 26.1 illustrates the data allocation process in RAID 0.

RAID 1

With RAID 1, data is cloned on a duplicate disk. This RAID method is therefore frequently called disk mirroring. Think of telling two people the same story so that if one forgets some of the details you can ask the other one to remind you.
When one of the disks in the RAID set fails, the other one continues to function. When the failed disk is replaced, the data is automatically cloned to the new disk from the surviving disk. RAID 1 also offers the possibility of using a hot standby spare disk that will be automatically cloned in the event of a disk failure on any of the primary RAID devices.
RAID 1 offers data redundancy, without the speed advantages of RAID 0. A disadvantage of software-based RAID 1 is that the server has to send data twice to be written to each of the mirror disks. This can saturate data busses and CPU use. With a hardware-based solution, the server CPU sends the data to the RAID disk controller once, and the disk controller then duplicates the data to the mirror disks. This makes RAID-capable disk controllers the preferred solution when implementing RAID 1.
A limitation of RAID 1 is that the total RAID size in gigabytes is equal to that of the smallest disk in the RAID set. Unlike RAID 0, the extra space on the larger device isn't used.
RAID 1 is supported by Fedora Linux. Figure 26.1 illustrates the data allocation process in RAID 1.

Figure 26-1 RAID 0 And RAID 1 Operation



RAID 4

RAID 4 operates likes RAID 0 but inserts a special error-correcting or parity chunk on an additional disk dedicated to this purpose.
RAID 4 requires at least three disks in the RAID set and can survive the loss of a single drive only. When this occurs, the data in it can be recreated on the fly with the aid of the information on the RAID set's parity disk. When the failed disk is replaced, it is repopulated with the lost data with the help of the parity disk's information.
RAID 4 combines the high speed provided of RAID 0 with the redundancy of RAID 1. Its major disadvantage is that the data is striped, but the parity information is not. In other words, any data written to any section of the data portion of the RAID set must be followed by an update of the parity disk. The parity disk can therefore act as a bottleneck. For this reason, RAID 4 isn't used very frequently.
RAID 4 is not supported by Fedora Linux.

RAID 5

RAID 5 improves on RAID 4 by striping the parity data between all the disks in the RAID set. This avoids the parity disk bottleneck, while maintaining many of the speed features of RAID 0 and the redundancy of RAID 1. Like RAID 4, RAID 5 can survive the loss of a single disk only.
RAID 5 is supported by Fedora Linux. Figure 26.2 illustrates the data allocation process in RAID 5.
Linux RAID 5 requires a minimum of three disks or partitions.

Figure 26-2 RAID 5 Operation


Before You Start

Specially built hardware-based RAID disk controllers are available for both IDE and SCSI drives. They usually have their own BIOS, so you can configure them right after your system's the power on self test (POST). Hardware-based RAID is transparent to your operating system; the hardware does all the work.
If hardware RAID isn't available, then you should be aware of these basic guidelines to follow when setting up software RAID.

IDE Drives

To save costs, many small business systems will probably use IDE disks, but they do have some limitations.
  • The total length of an IDE cable can be only a few feet long, which generally limits IDE drives to small home systems.
  • IDE drives do not hot swap. You cannot replace them while your system is running.
  • Only two devices can be attached per controller.
  • The performance of the IDE bus can be degraded by the presence of a second device on the cable.
  • The failure of one drive on an IDE bus often causes the malfunctioning of the second device. This can be fatal if you have two IDE drives of the same RAID set attached to the same cable.
For these reasons, I recommend you use only one IDE drive per controller when using RAID, especially in a corporate environment. In a home or SOHO setting, IDE-based software RAID may be adequate.

Serial ATA Drives

Serial ATA type drives are rapidly replacing IDE, or Ultra ATA, drives as the preferred entry level disk storage option because of a number of advantages:
  • The drive data cable can be as long as 1 meter in length versus IDE's 18 inches.
  • Serial ATA has better error checking than IDE.
  • There is only one drive per cable which makes hot swapping, or the capability to replace components while the system is still running, possible without the fear of affecting other devices on the data cable.
  • There are no jumpers to set on Serial ATA drives to make it a master or slave which makes them simpler to configure.
  • IDE drives have a 133Mbytes/s data rate whereas the Serial ATA specification starts at 150 Mbytes/sec with a goal of reaching 600 Mbytes/s over the expected ten year life of the specification.
If you can't afford more expensive and faster SCSI drives, Serial ATA would be the preferred device for software and hardware RAID

SCSI Drives

SCSI hard disks have a number of features that make them more attractive for RAID use than either IDE or Serial ATA drives.
  • SCSI controllers are more tolerant of disk failures. The failure of a single drive is less likely to disrupt the remaining drives on the bus.
  • SCSI cables can be up to 25 meters long, making them suitable for data center applications.
  • Much more than two devices may be connected to a SCSI cable bus. It can accommodate 7 (single-ended SCSI) or 15 (all other SCSI types) devices.
  • Some models of SCSI devices support "hot swapping" which allows you to replace them while the system is running.
  • SCSI currently supports data rates of up to 640 Mbytes/s making them highly desirable for installations where rapid data access is imperative.
SCSI drives tend to be more expensive than IDE drives, however, which may make them less attractive for home use.

Should I Use Software RAID Partitions Or Entire Disks?

It is generally a not a good idea to share RAID-configured partitions with non-RAID partitions. The reason for this is obvious: A disk failure could still incapacitate a system.
If you decide to use RAID, all the partitions on each RAID disk should be part of a RAID set. Many people simplify this problem by filling each disk of a RAID set with only one partition.

Backup Your System First

Software RAID creates the equivalent of a single RAID virtual disk drive made up of all the underlying regular partitions used to create it. You have to format this new RAID device before your Linux system can store files on it. Formatting, however, causes all the old data on the underlying RAID partitions to be lost. It is best to backup the data on these and any other partitions on the disk drive on which you want implement RAID. A mistake could unintentionally corrupt valid data.

Configure RAID In Single User Mode

As you will be modifying the disk structure of your system, you should also consider configuring RAID while your system is running in single-user mode from the VGA console. This makes sure that most applications and networking are shutdown and that no other users can access the system, reducing the risk of data corruption during the exercise.
[root@bigboy tmp]# init 1
Once finished, issue the exit command, and your system will boot in the default runlevel provided in the /etc/inittab file.

Configuring Software RAID

Configuring RAID using Fedora Linux requires a number of steps that need to be followed carefully. In the tutorial example, you'll be configuring RAID 5 using a system with three pre-partitioned hard disks. The partitions to be used are:
/dev/hde1
/dev/hdf2
/dev/hdg1
Be sure to adapt the various stages outlined below to your particular environment.

RAID Partitioning

You first need to identify two or more partitions, each on a separate disk. If you are doing RAID 0 or RAID 5, the partitions should be of approximately the same size, as in this scenario. RAID limits the extent of data access on each partition to an area no larger than that of the smallest partition in the RAID set.

Determining Available Partitions

First use the fdisk -l command to view all the mounted and unmounted filesystems available on your system. You may then also want to use the df -k command, which shows only mounted filesystems but has the big advantage of giving you the mount points too.
These two commands should help you to easily identify the partitions you want to use. Here is some sample output of these commands.
[root@bigboy tmp]# fdisk -l
 
Disk /dev/hda: 12.0 GB, 12072517632 bytes
255 heads, 63 sectors/track, 1467 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1        13    104391   83  Linux
/dev/hda2            14       144   1052257+  83  Linux
/dev/hda3           145       209    522112+  82  Linux swap
/dev/hda4           210      1467  10104885    5  Extended
/dev/hda5           210       655   3582463+  83  Linux
...
...
/dev/hda15         1455      1467    104391   83  Linux
[root@bigboy tmp]#
 
[root@bigboy tmp]# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda2              1035692    163916    819164  17% /
/dev/hda1               101086      8357     87510   9% /boot
/dev/hda15              101086      4127     91740   5% /data1
...
...
...
/dev/hda7              5336664    464228   4601344  10% /var
[root@bigboy tmp]#

Unmount the Partitions

You don't want anyone else accessing these partitions while you are creating the RAID set, so you need to make sure they are unmounted.
[root@bigboy tmp]# umount /dev/hde1
[root@bigboy tmp]# umount /dev/hdf2
[root@bigboy tmp]# umount /dev/hdg1

Prepare The Partitions With FDISK

You have to change each partition in the RAID set to be of type FD (Linux raid autodetect), and you can do this with fdisk. Here is an example using /dev/hde1.
[root@bigboy tmp]# fdisk /dev/hde
The number of cylinders for this disk is set to 8355. 
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
  (e.g., DOS FDISK, OS/2 FDISK)
 
Command (m for help):

Use FDISK Help

Now use the fdisk m command to get some help:
Command (m for help): m
  ...
  ...
  p   print the partition table
  q   quit without saving changes
  s   create a new empty Sun disklabel
  t   change a partition's system id
  ...
  ...
Command (m for help):

Set The ID Type To FD

Partition /dev/hde1 is the first partition on disk /dev/hde. Modify its type using the t command, and specify the partition number and type code. You also should use the L command to get a full listing of ID types in case you forget.
Command (m for help): t
Partition number (1-5): 1
Hex code (type L to list codes): L
 
 
...
...
...
16  Hidden FAT16    61   SpeedStor       f2  DOS secondary
17  Hidden HPFS/NTF 63  GNU HURD or Sys fd  Linux raid auto
18  AST SmartSleep  64  Novell Netware  fe  LANstep
1b  Hidden Win95 FA 65  Novell Netware  ff  BBT
Hex code (type L to list codes): fd
Changed system type of partition 1 to fd (Linux raid autodetect)
 
Command (m for help):

Make Sure The Change Occurred

Use the p command to get the new proposed partition table:
Command (m for help): p
 
Disk /dev/hde: 4311 MB, 4311982080 bytes
16 heads, 63 sectors/track, 8355 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
 
   Device Boot    Start       End    Blocks   Id  System
/dev/hde1             1      4088   2060320+  fd  Linux raid autodetect
/dev/hde2          4089      5713    819000   83  Linux
/dev/hde4          6608      8355    880992    5  Extended
/dev/hde5          6608      7500    450040+  83  Linux
/dev/hde6          7501      8355    430888+  83  Linux
 
Command (m for help):

Save The Changes

Use the w command to permanently save the changes to disk /dev/hde:
Command (m for help): w
The partition table has been altered!
 
Calling ioctl() to re-read partition table.
 
WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.
 
[root@bigboy tmp]#
The error above will occur if any of the other partitions on the disk is mounted.

Repeat For The Other Partitions

For the sake of brevity, I won't show the process for the other partitions. It's enough to know that the steps for changing the IDs for /dev/hdf2 and /dev/hdg1 are very similar.

Preparing the RAID Set

Now that the partitions have been prepared, we have to merge them into a new RAID partition that we'll then have to format and mount. Here's how it's done.

Create the RAID Set

You use the mdadm command with the --create option to create the RAID set. In this example we use the --level option to specify RAID 5, and the --raid-devices option to define the number of partitions to use.
[root@bigboy tmp]# mdadm --create --verbose /dev/md0 --level=5 \
   --raid-devices=3 /dev/hde1 /dev/hdf2 /dev/hdg1
 
mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 64K
mdadm: /dev/hde1 appears to contain an ext2fs file system
    size=48160K  mtime=Sat Jan 27 23:11:39 2007
mdadm: /dev/hdf2 appears to contain an ext2fs file system
    size=48160K  mtime=Sat Jan 27 23:11:39 2007
mdadm: /dev/hdg1 appears to contain an ext2fs file system
    size=48160K  mtime=Sat Jan 27 23:11:39 2007
mdadm: size set to 48064K
Continue creating array? y
mdadm: array /dev/md0 started.
[root@bigboy tmp]#

Confirm RAID Is Correctly Inititalized

The /proc/mdstat file provides the current status of all RAID devices. Confirm that the initialization is finished by inspecting the file and making sure that there are no initialization related messages. If there are, then wait until there are none.
[root@bigboy tmp]# cat /proc/mdstat
Personalities : [raid5]
read_ahead 1024 sectors
md0 : active raid5 hdg1[2] hde1[1] hdf2[0]
      4120448 blocks level 5, 32k chunk, algorithm 3 [3/3] [UUU]
 
unused devices: <none>
[root@bigboy tmp]#
Notice that the new RAID device is called /dev/md0. This information will be required for the next step.

Format The New RAID Set

Your new RAID partition now has to be formatted. The mkfs.ext3 command is used to do this.
[root@bigboy tmp]# mkfs.ext3 /dev/md0
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
36144 inodes, 144192 blocks
7209 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
18 block groups
8192 blocks per group, 8192 fragments per group
2008 inodes per group
Superblock backups stored on blocks: 
        8193, 24577, 40961, 57345, 73729
 
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
 
This filesystem will be automatically checked every 33 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
[root@bigboy tmp]#

Create the mdadm.conf Configuration File

Your system doesn't automatically remember all the component partitions of your RAID set. This information has to be kept in the mdadm.conf file. The formatting can be tricky, but fortunately the output of the mdadm --detail --scan --verbose command provides you with it. Here we see the output sent to the screen.
[root@bigboy tmp]# mdadm --detail --scan --verbose
ARRAY /dev/md0 level=raid5 num-devices=4 
UUID=77b695c4:32e5dd46:63dd7d16:17696e09
   devices=/dev/hde1,/dev/hdf2,/dev/hdg1
[root@bigboy tmp]#
 
Here we export the screen output to create the configuration file.
[root@bigboy tmp]# mdadm --detail --scan --verbose > /etc/mdadm.conf

Create A Mount Point For The RAID Set

The next step is to create a mount point for /dev/md0. In this case we'll create one called /mnt/raid
[root@bigboy mnt]# mkdir /mnt/raid

Edit The /etc/fstab File

The /etc/fstab file lists all the partitions that need to mount when the system boots. Add an Entry for the RAID set, the /dev/md0 device.
/dev/md0      /mnt/raid     ext3    defaults    1 2
Do not use labels in the /etc/fstab file for RAID devices; just use the real device name, such as /dev/md0. In older Linux versions, the /etc/rc.d/rc.sysinit script would check the /etc/fstab file for device entries that matched RAID set names listed in the now unused /etc/raidtab configuration file. The script would not automatically start the RAID set driver for the RAID set if it didn't find a match. Device mounting would then occur later on in the boot process. Mounting a RAID device that doesn't have a loaded driver can corrupt your data and produce this error.
Starting up RAID devices: md0(skipped)
Checking filesystems
/raiddata: Superblock has a bad ext3 journal(inode8)
CLEARED.
***journal has been deleted - file system is now ext 2 only***
 
/raiddata: The filesystem size (according to the superblock) is 2688072 blocks.
The physical size of the device is 8960245 blocks.
Either the superblock or the partition table is likely to be corrupt!
/boot: clean, 41/26104 files, 12755/104391 blocks
 
/raiddata: UNEXPECTED INCONSISTENCY; Run fsck manually (ie without -a or -p options).
If you are not familiar with the /etc/fstab file use the man fstab command to get a comprehensive explanation of each data column it contains.
The /dev/hde1, /dev/hdf2, and /dev/hdg1 partitions were replaced by the combined /dev/md0 partition. You therefore don't want the old partitions to be mounted again. Make sure that all references to them in this file are commented with a # at the beginning of the line or deleted entirely.
#/dev/hde1       /data1        ext3    defaults        1 2
#/dev/hdf2       /data2        ext3    defaults        1 2
#/dev/hdg1       /data3        ext3    defaults        1 2

Mount The New RAID Set

Use the mount command to mount the RAID set. You have your choice of methods:
  • The mount command's -a flag causes Linux to mount all the devices in the /etc/fstab file that have automounting enabled (default) and that are also not already mounted.
[root@bigboy tmp]# mount -a
  • You can also mount the device manually.
[root@bigboy tmp]# mount /dev/md0 /mnt/raid

Check The Status Of The New RAID

The /proc/mdstat file provides the current status of all the devices.
[root@bigboy tmp]# raidstart /dev/md0
[root@bigboy tmp]# cat /proc/mdstat
Personalities : [raid5]
read_ahead 1024 sectors
md0 : active raid5 hdg1[2] hde1[1] hdf2[0]
      4120448 blocks level 5, 32k chunk, algorithm 3 [3/3] [UUU]
 
unused devices: <none>
[root@bigboy tmp]#

Conclusion

Linux software RAID provides redundancy across partitions and hard disks, but it tends to be slower and less reliable than RAID provided by a hardware-based RAID disk controller.
Hardware RAID configuration is usually done via the system BIOS when the server boots up, and once configured, it is absolutely transparent to Linux. Unlike software RAID, hardware RAID requires entire disks to be dedicated to the purpose and when combined with the fact that it usually requires faster SCSI hard disks and an additional controller card, it tends to be expensive.
Remember to take these factors into consideration when determining the right solution for your needs and research the topic thoroughly before proceeding. Weighing cost versus reliability is always a difficult choice in systems administration.

Sunday, December 29, 2019

Understanding DNS setting

What is an MX Record

MX stands for Mail Exchange Records. MX records are used in DNS records(or Zone files) to specify how email should be routed.
Lets take an example of say liz@mydomain.com.
This is how a typical DNS record(for mydomain.com) looks like.

;
; Zone file for mydomain.com
 
 
 
 
 
 
 
 
 
@ 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com. (
                       109157199 
                       86000 
                       7200 
                       3600000 
                       600 ) 
mydomain.com. 14400 IN NS ns.mynameserver.com. 
mydomain.com. 14400 IN NS ns2.mynameserver.com. 
mydomain.com. 14400 IN NS ns3.mynameserver.com.
 
; A Record
mydomain.com. 14400 IN A 216.34.94.184
 
localhost.mydomain.com. 14400 IN A 127.0.0.1
 
; MX record
mydomain.com. 14400 IN MX 0 mydomain.com. 
 
mail 14400 IN CNAME mydomain.com. 
www 14400 IN CNAME mydomain.com. 
ftp 14400 IN CNAME mydomain.com. 
 

Notice the line with the ``MX'' in it. This is called the MX record.
mydomain.com. 14400 IN MX 0 mydomain.com. 
The MX record shows that all emails @ mydomain.com should be routed to the mail server at mydomain.com. The DNS record shows that mydomain.com is located at 216.34.94.184. This means that email meant for liz@mydomain.com will be routed to the email server at 216.34.94.184. This finishes the task of the MX record. The email server on that server(say sendmail) then takes over, collects the email and then proceeds to distribute it to the user ``liz''.
It is important that there be a dot(``.'') after the domain name in the MX record. If the dot is absent, it routes to ``mydomain.com.mydomain.com''. The number 0, indicates Preferance number. Mail is always routed to the server which has the lowest Preferance number. If there is only one mail server, it is safe to mark it 0.

Multiple mail servers

Multiple email servers are useful for the sake of redundancy. If the Highest Priority email server (one with the lowest Preference number) is down, then the email is routed to the Server with the second highest Preference number.
For example
mydomain.com. 14400 IN A 216.34.94.184
server2.mydomain.com. 14400 IN A 216.34.94.185
mydomain.com. 14400 IN MX 0 mydomain.com. 
mydomain.com. 14400 IN MX 30 server2.mydomain.com. 
You can have unlimited MX entries for Fallback.
If all the MX records are equal Preference numbers, the client simply attempts all equal Preference servers in random order, and then goes to MX record with the next highest Preference number.

Pointing MX records to an IP

Its not possible to have an MX record pointing directly to an IP. For example 'mydomain.com. 14400 IN MX 0 216.34.94.184`` is wrong. Define an ``A Record'' first and then have the MX record pointing to it.
server2.mydomain.com. 14400 IN A 216.34.94.185
mydomain.com. 14400 IN MX 30 server2.mydomain.com. 

MX records for Subdomains

A Subdomain is something like this ``Subdomain.mydomain.com''. Assume you want to send an email to liz@subdomain.mydomain.com and to capture that on another server.
mydomain.com. 14400 IN A 216.34.94.184
server2.mydomain.com. 14400 IN A 216.34.94.185
mydomain.com. 14400 IN MX 30 mydomain.com. 
subdomain.mydomain.com. 14400 IN MX 30 server2.mydomain.com. 
In this configuration, liz@subdomain.mydomain.com would go to 216.34.94.185 and liz@mydomain.com would go to 216.34.94.184.

Testing the MX record

Once you setup your MX record, always test it to see if it is setup correctly. You can do with tools like nslookup.

[root@localhost sangeetha]# nslookup
> set q=mx 
> yahoo.com 
Server: 192.168.1.1 Address: 192.168.1.1#53
Non-authoritative answer: 
yahoo.com mail exchanger = 1 mx1.mail.yahoo.com. 
yahoo.com mail exchanger = 1 mx2.mail.yahoo.com. 
yahoo.com mail exchanger = 1 mx3.mail.yahoo.com. 
yahoo.com mail exchanger = 5 mx4.mail.yahoo.com.
Authoritative answers can be found from: 
yahoo.com nameserver = ns2.yahoo.com. 
yahoo.com nameserver = ns3.yahoo.com. 
yahoo.com nameserver = ns4.yahoo.com. 
yahoo.com nameserver = ns5.yahoo.com. 
yahoo.com nameserver = ns1.yahoo.com. 
mx1.mail.yahoo.com internet address = 4.79.181.14 
mx1.mail.yahoo.com internet address = 4.79.181.15 
mx1.mail.yahoo.com internet address = 67.28.113.10 
mx1.mail.yahoo.com internet address = 67.28.113.11 
ns1.yahoo.com internet address = 66.218.71.63 
ns2.yahoo.com internet address = 66.163.169.170 
ns3.yahoo.com internet address = 217.12.4.104 
ns4.yahoo.com internet address = 63.250.206.138 
ns5.yahoo.com internet address = 216.109.116.17 

Sunday, December 22, 2019

IT Policy Document


 Information Technology Policies
And Procedures
Company Name
Introduction

Company Name’s information technology resources constitute a valuable Company name’s asset that must be managed accordingly to ensure their integrity, security, and availability for work, research and business activities. Carrying out this mission requires the company to establish basic Information Security policies and standards and to provide both access and reasonable Security at an acceptable cost. The Company Information Technology Policies and Procedures are intended to facilitate and support authorized access to Company information.
The purpose of the Company Information Policies and Procedures is:
To establish company-wide Protocol for Information Security.
To help identify and prevent the compromise of Information Security and the misuse of Company information technology resources.
To protect the reputation of the Company and to allow the Company to satisfy its legal and ethical responsibilities with regard to its information technology resources.
To enable the Company to respond to complaints and queries about real or perceived non-compliance with the Company Information Technology Policies and Procedures.

Responsibility

Authorized Users of Company information technology resources are personally responsible for complying with all Company policies, procedures and standards relating to Information Security, regardless of data center or location and will be held personally accountable for any misuse of these resources.
Approvals

This Document in its initial form has received the following review and approvals from Company name Management:


________________       ______________          _____________
                                        Title                                    Date


________________       ______________          _____________
                                           Title                                   Date



Table of Contents
Unauthorized Use Policy.............................................................................3
Guest User Policy........................................................................................4
Company Confidentiality Policy.................................................................5
Acceptable Use Policy.................................................................................6
Electronic Communications Policy............................................................10
Password Policy.........................................................................................11
Acceptable Encryption Policy....................................................................14
Remote Access Policy................................................................................15
Physical Security Policy.............................................................................17
Workstation Configuration Security Policy...............................................19
Server Configuration Security Policy........................................................21
“De-Militarized Zone” Network Equipment Policy..................................23
Router Security Policy...............................................................................26
Wireless Communication Policy................................................................27
Change Management Policy......................................................................28
Information Security Audit Policy.............................................................29
Unauthorized Use Policy

1.      Purpose.
This policy sets forth the Company name’s policy regarding Unauthorized Use of the Company Information Technology Network.

2.      Scope.
This policy covers all Unauthorized Use of the Company Information Technology Network, whether such Unauthorized Use is done by a person who is not an Authorized User, or by an Authorized User who exceeds the limits of that person’s authorization whose use exceeds Authorized Use permitted by the Company, all of whom are referred to in this policy as “Unauthorized Users.”

3.      Policy.
·         All Unauthorized Users are prohibited from using Company Information Technology Network for any purpose whatsoever. Authorized Users are prohibited from using the Company Information Technology Network in any way that exceeds the limits of their individual authorization.
·         The Computing and networking facilities of the Company are intended for use for administration in support of the Company mission.
·         Access granted as a privilege to staff and the Company reserves the right to limit, restricts, or extends access to the facilities.
·         The Company IT facilities are not to be use for commercial/Personal purposes or non-Company-related activities.

4.      Enforcement.
Unauthorized Users may be subject to criminal prosecution and/or civil suits in which the Company seeks damages and/or other legal and/or equitable remedies. Unauthorized Users who are employees of the Company may also be subject to disciplinary action, up to and including termination of employment.

Guest User Policy  
1.      Purpose.
The Company sharing and meeting with the buyers’ agent.
Companies held regular pp meeting with buyer and some supplier. In doing so, Company often grants to Company guests and visitors the right to use Internet with connected to Company Public WIFI, and cannot be allow connect to Company’s Corporate WIFI.

2.      Scope.
This policy applies only to any Guest Users and does not include staff, or guest from The Companies group.

3.      Policy.
A Guest User is an Authorized User when utilizing the Company’s information technology resources in compliance with the Company Information Technology Policies and Procedures and as long as the use remains within the limits of the Guest User’s individual authorization. The Guest User may not be authorized to use computers in the Company. The Guests only permitted using the WIFI’s guest in the specified area.

4.      Enforcement.
Any Authorized User found to be in violation of this policy will be considered an Unauthorized User, and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use Policy.
Company Confidentiality Policy
  1. Purpose.
Confidential information may be developed or obtained by Company employees/interns as a result of that person’s relationship with the Company.

  1. Scope.
All Authorized Users who have contact with and access to confidential information must keep such information confidential. Confidential information includes, but is not limited to, the following types of information:
•    Staff and employee information, such as address, telephone number, KTP number, birth date and other private information.
•    Operations manuals, Company practices, marketing plans, techniques and materials, development plans, and financial information.
•    Staff or applicant lists, personnel and payroll records, records regarding vendors and suppliers, records and files of the Company, and other information concerning the business affairs or operating practices of the Company.

  1. Policy.
Confidential information must never be released, removed from the Company premises, copied, transmitted, or in any other way used by the Authorized User for any purpose outside the scope of their Company employment, nor revealed to non-Company employees, without the express written consent of Company management personnel.
Information stored on the Company Information Technology Network is confidential and may not be distributed outside the Company except in the course of the Company’s business or as otherwise authorized by management personnel. Authorized Users may not remove or borrow from the Company premises any computer equipment, disks, or related technology, product or information unless authorized to do so.

  1. Enforcement.
Any Authorized User found to be in violation of this policy will be considered an Unauthorized User, and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use Policy.

Acceptable Use Policy
  1. Overview.
This policy is intended to protect the Company, employees, and staff as well as the Company from the consequences of illegal or damaging actions by individuals using the Company Information Technology Network.
The Company Information Technology Network includes: Internet/Intranet/Extranet-related systems, including but not limited to computer/Networking equipment, Software, Operating Systems, storage media, Network accounts providing electronic mail, VOIP (Voice Over Internet Protocol), HRD’s information system, WWW browsing, and FTP, which are the property of the Company. They are to be used for Company business purposes and to serve the interests of the Company and are intended for use for administration in support of the Company mission, and as well as all Authorized Users. Effective computer Security is a team effort requiring the participation and support of every employee, Staff and Authorized User who deals with information and/or information systems. It is the responsibility of every computer user to know the Company Information Technology Policies and Procedures, and to comply with the Company Information Technology Policies and Procedures.


  1. Purpose.
This policy describes the Authorized Use of the Company Information Technology Network and protects the Company and Authorized Users. Unauthorized uses expose the Company to many risks including legal liability, Virus attacks, and the compromise of Network systems, Services, and information.

  1. Scope.
This policy applies to all persons with a Company-owned, third party-owned, or personally-owned computing device that is connected to the Company Information Technology Network.

  1. Policy.
a.       General Use and Ownership:
1.      Data created by Authorized Users that is on the Company Information Technology Network is the property of the Company. There is no guarantee that information stored on the Company Information Technology Network device will be confidential
2.      Authorized Use includes reasonable personal use of the Company Information Technology Network by Authorized Users. Company departments are responsible for creating guidelines concerning personal use of the Company Information Technology Network. In the absence of such guidelines, employees or staff should consult their supervisor, manager, or the Information Security Guidelines.
3.      Any information that an Authorized User considers to be sensitive or vulnerable should be encrypted. For guidelines on information classification, see Information Security's Information Sensitivity Policy. For guidelines on encrypting Email and documents, consult Information Security's Awareness Initiative.
4.      Authorized Company employees may monitor the Company Information Technology Network traffic at any time, in accordance with the Information Security Audit Policy.


b.      Security and Proprietary Information.
1.      Authorized Users are required to classify the user interface for information contained on the Company Information Technology Network as “confidential” or “not confidential,” as defined by Company Confidentiality Guidelines. Confidential information includes, but is not limited to: Company private data, specifications, student information, and research data. Employees are required to take all necessary steps to prevent unauthorized access to this Sensitive Information.
2.      Authorized Users are responsible for the Security of their passwords and accounts and must keep passwords confidential and are not permitted to share accounts.
3.      Authorized Users are responsible for logging out of all systems and accounts when they are not being used; they must not be left unattended.
4.      All Laptops and workstation that are part of or connected to the Company Information Technology Network are required to be secured with a password-protected screensaver with the automatic activation feature set at 10 minutes or less, or by logging-off when the device will be unattended.
5.      Encryption of information must be used in compliance with Information Security's Acceptable Encryption Use Policy.
6.      Authorized Users are required to exercise special care to protect laptop computers that are part of or connected to the Company Information Technology Network in accordance with the “Laptop Security Guidelines.”
7.      Postings by Authorized Users from a Company Email address must contain a disclaimer stating that the opinions expressed are strictly those of the author and not necessarily those of the Company, unless posting has been done in the course of Company business.
8.      All Computers used by Authorized Users that are connected to the Company Information Technology Network, whether owned by the individual or the Company, must be continually executing approved Virus-scanning Software with a current Virus Database.
9.      Authorized Users must use extreme caution when opening e-mail attachments received from unknown senders, which may contain Viruses, e-mail bombs, or Trojan Horse codes.

c. Unacceptable Use of the Company Information Technology Network.
The following activities are prohibited, although Company employees who are Authorized Users may be exempted from these restrictions during the performance of their legitimate job responsibilities. Under no circumstances is an Authorized User permitted to engage in any activity that is illegal under local, state, federal or international law while utilizing the Company Information Technology Network.
Unacceptable use includes, but is not limited to the following activities:

System and Network Activities
The following activities are strictly prohibited, with no exceptions:
1.      Violations of the rights of any person or company protected by copyright, trade secret, patent or other Intellectual Property, or similar laws or regulations, including, but not limited to, the installation or distribution of copyrighted or other Software products that are not licensed for use by the Company.
2.      Unauthorized copying of copyrighted material including, but not limited to, digitization and distribution of photographs from magazines, books or other copyrighted sources, copyrighted music, and the installation of any copyrighted Software for which the Company or the Authorized User does not have an active license is strictly prohibited.
3.      Exporting Software, technical information, Encryption Software or technology, in violation of international or regional export control laws, is illegal. Company management must be consulted prior to export of any material that is in question.
4.      Introduction of Malicious Software into the Company Information Technology Network (e.g., Viruses, Worms, Trojan Horses, e-mail bombs, etc.).
5.      An Authorized User’s revelation of that person’s account password to others or allowing use of an Authorized User’s account by others, including family and other household members when an Authorized User’s computer is connected to the Company Information Technology Network from home or other non-Company locations.
6.      The use of a component of the Company Information Technology Network or other computing asset to actively engage in procuring or transmitting material that violates sexual harassment or hostile workplace laws or that violates any Company policy. Pornographic material is a violation of sexual harassment policies.
7.      Making fraudulent offers of products, items, or services originating from any Company account or otherwise made from a computer connected to the Company Information Technology Network.
8.      Causing Security breaches or disruptions of communication over the Company Information Technology Network. Security breaches include, but are not limited to, accessing data or other communications of which the Authorized User is not an intended recipient or logging into an account that the Authorized User is not expressly authorized to access. For purposes of this section, "disruption" includes, but is not limited to, Network Sniffing, traffic floods, Packet Spoofing, Denial of Service, etc.
9.      Port Scanning or Security Scanning is expressly prohibited unless prior notification to Information Security is made.
10.   Executing any form of Network monitoring which will intercept data not intended for the Authorized User is expressly prohibited, unless this activity is a part of the Authorized User’s normal job/duty.
11.   Circumventing User Authentication or Security of any device, Network, or account.
12.   Interfering with or denying Service to any user other than the individual's Host (for example, a Denial of Service attack).
13.   Using any Program/script/command, or sending messages of any kind, with the intent to interfere with or disable a user's terminal session, via any means locally or remotely.
14.   Providing information about, or lists of, Company employees or Staff to non-Company parties.



Email and Communications Activities.
1.      Requesting new account Mail must send to IT Administrator by Supervisor for activating.
2.      Authorized User must not use non-Company Email accounts (e.g. Hotmail, Yahoo, Gmail and AOL) or other external resources.
3.      Sending unsolicited Email messages, including the sending of "junk mail" or other advertising material to individuals who did not specifically request such material (Email SPAM).
4.      Any form of harassment via Email, instant messenger, telephone, whether through language, frequency, or size of messages.
5.      Unauthorized use, or forging, of Email header information.
6.      Solicitation of Email for any other Email address, other than that of the Authorized User’s own account, with the intent to harass or to collect replies.
7.      Creating or forwarding Chain email, Phishing, or other scams of any type.
8.      Use of the Company’s name in any unsolicited Email on behalf of, or to advertise, any service or product without the explicit written permission of the Company.
9.      Posting the same or similar non-business-related messages to large numbers of Usenet newsgroups (newsgroup SPAM).

  1. Enforcement.
Any Authorized User found to be in violation of this policy will be considered an Unauthorized User, and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use policy.


Electronic Communications Policy

  1. Purpose.
Electronic communications systems that utilize the Company Information Technology Network are not an open forum, but rather are owned and operated by the Company to communicate inter-company, and to conduct official Company business. Authorized Users may use these systems only within the scope of Company Information Technology Policies and Procedures. Electronic communication systems include, but are not limited to: all electronic mail and Skype Messaging systems, web content, and Internet access.

  1. Scope.
This policy covers appropriate use of any electronic message sent from a Company account, and applies to all Authorized Users of the Company Information Technology Network.

  1. Policy.
Prohibited Use
The Company Email system must not to be used for the creation or distribution of any disruptive or offensive messages may not be used for personal business or personal gain, except as permitted by management
Personal Use
Authorized Users may use a reasonable amount of Company resources for personal Emails. However, non-work related Email shall be saved in a separate folder from work related Email. 
Signatures
Signatures in Emails and other electronic messages may contain some or all of the following only: name, title, department name, name of Company, and workplace contact information (phone number, fax number, mailing address, Email address). Quotations, such as proverbs, witticisms, etc., are not allowed in signatures.
Monitoring
Authorized Users of Company accounts shall have no expectation of privacy in anything they store, send or receive in a Company’s Information Technology Network. The IT Administrator may monitor communication on the Company Information Technology Network without prior notice, but is not obliged to do so.

  1. Enforcement.
Any Authorized User found to be in violation of this policy will be considered an Unauthorized User,  IT Administrator may suspend any person from using the computing and network facilities and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use Policy.
Password Policy
  1. Overview.
Passwords are essential to computer Security. They are the front line of protection for Authorized User accounts. A poorly chosen password can result in the compromise of the entire Company Information Technology Network. All Authorized Users are responsible for taking the actions outlined below, to select and secure their passwords.

  1. Purpose.
The purpose of this policy is to establish a standard for creation and protection of strong passwords for Authorized Users of information technology resources on the Company Information Technology Network. This policy will also establish the frequency of change for those passwords.

  1. Scope.
The scope of this policy includes all Authorized Users who are responsible for an account (or any form of access that supports or requires a password) on any system that resides at any Company facility, accesses the Company Information Technology Network.

  1. Policy.
General
• All system-level passwords (e.g. the "root" account on UNIX-based Operating Systems, the "enable" functionality of Routers, the Windows "administrator" account, application administration accounts, VOIP, etc.) must be changed on at least a quarterly basis.
• All system-level passwords on all equipment must be part of the Company Password Management System.
• All user-level passwords (e.g. Email, web, desktop computer, etc.) must be changed at least every Three month and are to be changes quarterly, by IT Administrator.
• Authorized User accounts that have system-level privileges granted through group memberships or Programs such as “sudo” or “SU” must have a unique password that is different from all other accounts held by that Authorized User.
• Passwords must not be included in Email messages, phone conversations, or other forms of electronic communication.
• All user-level and system-level passwords must conform to the guidelines described below.

Standards
a. General Password Construction Guidelines
Passwords are used for various purposes at the Company. Some of the more common uses include: user-level accounts, Email accounts, screen saver protection, VOIPl passwords, and local Router logins.
Poor, weak passwords have the following characteristics:
• The password contains less than eight characters
• The password is a word found in a dictionary (English or foreign)
• The password is a common usage word, such as:
• Names of family members, pets, friends, co-workers, fictional characters, etc.
• Computer terms and names, commands, sites, companies, Hardware and Software terms
• Birthdays and other personal information, such as addresses and phone numbers
• Word or number patterns like aaabbb, qwerty, xyzzy, 123321, etc.
• Any of the above spelled backwards
• Any of the above preceded or followed by a digit (e.g. secret1, 1secret)
Strong passwords have the following characteristics:
• The password contains both upper and lower case characters (e.g. a-z, A-Z)
• The password has digits and punctuation characters as well as letters, if possible
(e.g. 0-9, !@#$%^&*()_+|~-=\`{}[]:";'<>?,./)
• The password is at least eight alpha-numeric characters long
• The password is not a word in any language, slang, dialect, jargon, etc.
• The password is not based on personal information, names of family, etc.
Passwords must never be written down or stored on-line. Passwords should be created so that they can be easily remembered while still having strong password characteristics. One way to do this is to create a password derived from a song title, affirmation, or other phrase. For example, the phrase might be "This May Be One Way To Remember" and the corresponding password might be "TmB1w2R!", or "Tmb1W>r~", or some other variation.
NOTE: These particular examples are now public, and must not be used as real passwords!

b. Password Protection Standards
Authorized Users must not use the same password for Company accounts as for other non-Company access (e.g. personal ISP account, etc.). Wherever possible, the same password must not be used for various Company access needs. For example, the password for the CARS systems must be separate from the password for other Information Technology systems. Also, a separate password must be selected for a Windows account and a UNIX account.
Company passwords must not be shared with anyone, including administrative assistants or secretaries. All passwords are to be treated as confidential Company information. Groups accounts (an account shared among two or more users) are prohibited.
Users must not do the following:
• Passwords must not be revealed or hinted at over the phone to anyone without proper verification, in an Email message which includes the user name, to any supervisors or co-workers, on questionnaires or Security forms, or to family members.
• The "Remember Password" feature of applications (e.g. Eudora, Outlook, Thunderbird or Netscape Messenger) must not be used.
If someone demands a password, they should be referred to this document or they should call IT personnel.
Again, passwords must not be written down and stored anywhere by the Authorized User. Passwords must not be stored in a file on ANY computer system without Encryption.
If an account or password is suspected to be compromised, the incident must be reported to IT personnel and the password must be changed immediately.
Password Cracking or guessing may be performed on a periodic or random basis by IT personnel. If a password is guessed or cracked during one of these scans, the user will be required to change it.

c. Application Development Standards
Application developers must ensure their Programs contain the following Security precautions:
• Applications must support User Authentication of individual Authorized Users, not groups.
• Applications must not store passwords in clear text or in any easily reversible form.
• Applications must provide for some sort of role management, so that one Authorized User can take over the functions of another without having to know the other's password.

d. Use of Passwords and Pass-phrases for Remote Access Users
Remote Access to the Company Information Technology Network must be controlled using either one-time password authentication or a public / private key system with a strong Pass-phrase.

e. Pass-phrases
Pass-phrases are generally used for public / private key authentication. A public / private key system defines a mathematical relationship between the public key that is known by all, and the private key, that is known only to the Authorized User. Without the Pass-phrase to "unlock" the private key, the Authorized User cannot gain access.
Pass-phrases are not the same as passwords. A Pass-phrase is a longer version of a password and is, therefore, considered more secure. A Pass-phrase is typically composed of multiple words. Because of this, a Pass-phrase is more secure against "dictionary attacks."
A good Pass-phrase is relatively long and contains a combination of upper- and lower-case letters, numerals, and punctuation characters. The following is an example of a good Pass-phrase:
"R34d car3fu!!y. B3 h0n3$t."
All of the rules above that apply to passwords, also apply to Pass-phrases

  1. Enforcement.
Any Authorized User found to be in violation of this policy will be considered an Unauthorized User, and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use Policy.


Acceptable Encryption Policy

  1. Purpose.
The purpose of this policy is to limit the use of Encryption by Authorized Users to methods that receive substantial work effectively. Additionally, this policy provides direction to ensure compliance with buyer’s regulations, and to ensure legal authority is granted for the dissemination and use of Encryption technologies outside of the Country.

  1. Scope.
This policy applies to all Authorized Users including employees and affiliates.

  1. Policy.
Proven, standard Encryption methods (e.g. DES, Blowfish, RSA, RC5, IDEA, etc.) must be used as the basis for Encryption technologies. These methods represent the actual Cipher used for an approved application. For example, Network Associate's Pretty Good Privacy (PGP) technology uses the IDEA method in combination with RSA or Diffie-Hellman methods, while Secure Socket Layer (SSL) technology uses RSA Encryption. Symmetric Cryptosystem key lengths must be at least 128 bits. Asymmetric Cryptosystem keys must be of a length that yields equivalent strength. Company’s key length requirements are reviewed annually and upgraded as technology allows.
Authorized Users may not use Proprietary Encryption Algorithms for any purpose, unless reviewed by qualified experts outside of the vendor in question and approved by Information Security personnel. Be aware that the export of Encryption technologies is restricted by the U.S. Government. Residents of countries other than the United States need to be aware of the Encryption technology laws of the country in which they reside.

  1. Enforcement.
Any Authorized User found to be in violation of this policy will be considered an Unauthorized User, and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use Policy.

Remote Access Policy

  1. Purpose.
This policy defines standards for connecting to the Company Information Technology Network from any Host. These standards are designed to minimize potential exposure of the Company to damages that result from Unauthorized Use of the Company Information Technology Network. Damages include, but are not limited to: the loss of sensitive or confidential data, loss of Intellectual Property, damage to the Company’s VOIP Communication, damage to the Company’s internal systems, and financial damages of all kinds.

  1. Scope.
This policy applies to all Authorized Users including Company staff, employees and affiliates, who utilize Company-owned or personally-owned information technology resources to connect such devices to the Company Information Technology Network. This policy applies to Remote Access connections used to do work on behalf of the Company, including but not limited to Email correspondence and accessing Intranet web resources.
Remote Access implementations that are covered by this policy include, but are not limited to: dial-up Modems, Frame Relays, Integrated Services Digital Network (ISDN) connections, Digital Subscriber Line (DSL) connections, Cable Modems, etc.

  1. Policy.
General
1. Authorized Users with Remote Access privileges to the Company Information Technology Network must ensure that their Remote Access connection complies with the Company Information Technology Policies and Procedures, and treat it with the same consideration as their on-site connection to the Company.
2. General access to the Internet through the Company Information Technology Network is not permitted.
3. Authorized Users must review the following policies to determine how to protect information when accessing the Company Information Technology.
Network via Remote Access methods, and for acceptable use of the Company Information Technology Network:
a. The Company Acceptable Encryption Policy
b. The Company Team Viewer/VNC Policy
c. The Company Wireless Communications Policy
d. The Company Acceptable Use Policy
4. For additional information regarding the Company's Remote Access connections, Authorized Users should contact the Information Technology Department.

Requirements
1. Secure Remote Access must be strictly controlled. Control will be enforced via one-time password authentication or public / private keys with strong Pass-phrases. For information about how to create a strong Pass-phrase, Authorized Users should refer to the Password Policy.
2.  Authorized Users must not provide their login identification to the Company Information Technology Network or its resources to anyone, not even family members.
3. Authorized Users who, as a Company employee or affiliates with Remote Access privileges, must ensure that Company-owned or personal information technology resources are not connected to any other Network at the same time they are connected to the Company Information Technology Network (with the exception of personal Networks that are under the complete control of the Authorized User).
4.  Authorized Users who, as a Company employee or affiliates with remote Authorized User access privileges to the Company Information Technology Network must not use non-Company Email accounts (e.g. Hotmail, Yahoo, and AOL) or other external resources to conduct Company business, thereby ensuring that official business is never confused with personal business.
5.  Routers for dedicated ISDN lines configured for access to the Company Information Technology Network must meet the minimum authentication requirements of the Challenge Handshake Authentication Protocol (CHAP).
6. Reconfiguration of an Authorized User’s home equipment for the purpose of Split-Tunneling or Dual Homing is not permitted.
7. Frame Relay must meet the minimum authentication requirements of Data-Link Connection Identifier (DLCI) standards.
8. Non-standard Hardware configurations must be approved by Information Technology personnel, and Information Technology personnel must approve Security configurations for access to Hardware.
9. All Hosts that are connected to the Company Information Technology Network via Remote Access technologies, including personal computers, must use the most recent corporate-standard Anti-Virus Software. Third-party connections to the Company Information Technology Network must comply with requirements as stated in the Third Party Agreement Documentation.
10. Personal equipment that is used to connect to the Company Information Technology Network must meet the same requirements applied to Company-owned equipment for Remote Access.
11. Organizations or Authorized Users who wish to implement non-standard Remote Access solutions to the Company Information Technology Network must obtain prior written approval from the Information Technology Department.

  1. Enforcement.
Any Authorized User found to be in violation of this policy will be considered an Unauthorized User, and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use Policy.

Physical Security Policy

  1. Overview.
Physical Security means providing environmental safeguards for, and controlling physical access to, equipment and data on the Company Information Technology Network in order to protect information technology resources from Unauthorized Use, in terms of both physical Hardware and data perspectives.
  1. Purpose.
The purpose of this policy is to establish standards for granting, monitoring, and terminating physical access to the Company Information Technology Network and to protect equipment on the Company Information Technology Network from environmental factors.
  1. Scope.
This policy applies to the entire Company Information Technology Network, including but not limited to Finger Print/Door lock Network, CCTV Network, and the Information Technology Services Network Operations Center.
  1. Policy.
Environmental Safeguards
1. Adequate air conditioning must be operational in Company Information Technology Network facilities that house information technology resources, to prevent long-term heat damage and equipment failure.
2. All Company Information Technology Network facilities must have adequate fire extinguishing devices present in the office area. These devices must be inspected by Company General Affair/Compliance personnel.
3.  All Company Information Technology Network information technology resources must be fitted with effective Surge Protectors to prevent power spikes and subsequent damage to data and Hardware.
4. Critical Company Information Technology Network information technology resources must each be connected to an Uninterrupted Power Supply (UPS) in order to prevent power spikes, brownouts, and subsequent damage to data and Hardware.
5. Electrical outlets must not be overloaded by connecting too many devices. Proper and practical usage of extension cords are to be reviewed annually.
Physical Access
1. All Company Information Technology Network physical Security systems must comply with all regulations, including, but not limited to, building codes and fire prevention codes.
2.  Physical access privileges to all Company Information Technology Network facilities must be documented and managed by Information Technology Department.
3. All facilities that house Company Information Technology Network information technology resources must be physically protected in proportion to the importance of their function.
4. Access to Company Information Technology Network restricted facilities will be granted only to Company staff and affiliates whose job responsibilities require access to that facility.
5. The process for granting card or key access to Company Information Technology Network facilities must include approval from the Company Manager of Information Technology.
6. Secured access devices (e.g. access cards, keys, combinations, etc.) must not be shared with or loaned to others by Authorized Users.
7. Secured access devices that are no longer needed must be returned to the  Information Technology department, and logged appropriately before they are re-allocated to another Authorized User.
8.  Lost or stolen Company Information Technology Network secured access devices must be reported to Information Technology personnel immediately.
9. The Company Employees responsible for Company Information Technology Network facilities must remove the secured access device rights of individuals that no longer require access.
10. Company Visitors and other invitees must be escorted and monitored while in restricted Company Information Technology Network facilities.
11. Company Employees responsible for Company Information Technology Network facilities must review access records and visitor Logs for the facility on a periodic basis, and investigate any unusual access.
12. All spaces housing information technology resources must be kept locked when not occupied by a Company Employee, in order to reduce the occurrence of unauthorized entry and access.
      5.  Enforcement.  
Any Authorized User found to be in violation of this policy will be considered an      Unauthorized User, and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use Policy.

Workstation Configuration Security Policy

  1. Purpose.
The purpose of this policy is to establish standards for the base configuration of workstations that are owned or operated by the Company. Effective implementation of this policy will minimize unauthorized access to the Company Information Technology Network and other Proprietary Information and technology.

  1. Scope.
This policy applies to all Company Information Technology Network workstation equipment owned or operated by the Company, and to workstations registered under any Company-owned internal Network domain.

  1. Policy.
Ownership and Responsibilities
All Company Information Technology Network workstations at the Company must be the responsibility of an operational group that is responsible for system administration. Approved workstation configuration standards must be established and maintained by IT Administrator. IT Administrator must monitor configuration compliance and request special approval for any noted exceptions.
1.  Workstations must be registered within the Company IT Management System. At a minimum, the following information is required to positively identify the point of contact:
a. Workstation location
b. Hardware and Operating System (OS) version numbers
c. Main functions and applications, if applicable
2. Information in the Company Management System must be kept current.

General Configuration Standards
1. OS configuration must comply with approved Information Technology Standards.
2. Services and applications that are unused must be disabled where practical. Exceptions must be noted and approved by authorized Information Technology personnel.
3. Access to Services must be protected through authorized access-control methods (e.g. TCP wrappers), if possible.
4. The most recent Security Patches must be installed on the system as soon as practical, the only exception being when immediate application would interfere with business requirements.
5. Trust Relationships between systems constitute a Security risk, and their use should be avoided and should not be used when another method of communication will suffice.
6. The standard Security principle of Least Required Access must be utilized when performing a function.
7. If a methodology for Secure Channel connection is available (i.e. technically feasible), privileged access must be performed over Secure Channels (e.g. encrypted Network connections using IPSec or Secure Shell).

Monitoring
Security-related events must be reported to appropriate Information Technology personnel, who review Logs and report incidents to IT Administrator. Corrective measures are prescribed as needed. Security-related events include (but are not limited to):
1. Port scan attacks
2. Evidence of unauthorized access to privileged accounts or data
3. Anomalous occurrences that are not related to specific applications on the Host

Compliance
1. Audits are performed on a regular basis by authorized parties within the Company.
2. Audits are managed by the Company’s appropriate Information Technology personnel, in accordance with the Compliance Policy documentation. Findings not related to a specific operational group are filtered by Information Technology personnel, and then presented to the appropriate support staff for remediation or justification.
3. Reasonable efforts are made to prevent audits from causing operational failures or disruptions.
      4.  Enforcement.
Any Authorized User found to be in violation of this policy will be considered an Unauthorized User, and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use Policy.
Server Configuration Security Policy

  1. Purpose.
The purpose of this policy is to establish standards for the base configuration of server equipment that is owned or operated by the Company. Effective implementation of this policy will minimize Unauthorized Use of the Company Information Technology Network or other access to the Company’s Proprietary Information and technology.

  1. Scope.
This policy applies to server equipment owned or operated by the Company, and to servers registered under any Company-owned internal Network domain.
This policy applies specifically to equipment connected to the internal Company Information Technology Network. For secure configuration of equipment external to the Company on the “De-Militarized Zone” (DMZ), refer to the Company ”De-Militarized Zone” Equipment Policy documentation.

  1. Policy.
Ownership and Responsibilities
All internal servers deployed at the Company must be the responsibility of an system administration. Approved server configuration standards must be established and maintained by IT Manager, based on business needs. IT Administrator must monitor configuration compliance and request special approval for any noted exceptions. IT Administrator must establish a process for changing the configuration standards, which includes review and approval by Information Security personnel.
1. Servers must be registered within the Company Security Management System. At a minimum, the following information is required to positively identify the point of contact:
a. Server location.
b. Hardware and Operating System (OS) version numbers
c. Main functions and applications, if applicable
2. Information in the Company Security Management System must be kept current.
3. Configuration changes made by Authorized Users for operational servers must comply with the Change Management Policy documentation.

General Configuration Standards
1. OS configuration must be in accordance with approved Information Security Standards.
2. Services and applications that are unused must be disabled where practical. Exceptions must be noted and approved by Information Technology Admin.
3. Access to Services must be logged or protected through appropriate Access Control methods (e.g. TCP wrappers), if possible.
4. The most recent Security Patches must be installed on the system as soon as practical, the only exception being when immediate application would interfere with business requirements.
5. Trust Relationships between systems are a Security risk, and their use should be avoided. Do not use a Trust Relationship when some other method of communication will do.
6. Authorized Users must always use the standard Security principle of Least Required Access to perform a function.
7. If a methodology for Secure Channel connection is available (i.e. technically feasible), privileged access must be performed over Secure Channels (e.g. encrypted Network connections using IPSec or Secure Shell).
8. All servers must be physically located in an access-controlled environment.
9. Authorized Users are specifically prohibited from operating servers in uncontrolled office areas.

Monitoring
1. All Security-related events on critical or sensitive systems must be logged by Information Technology personnel saved as follows:
a. All Security-related Logs must be kept online as required in the specific server standards document.
b. Daily incremental tape Backups must be retained as required in the specific server standards document.
c. Weekly full tape Backups of Logs must be retained as required in the specific server standards document.
d. Monthly full Backups must be retained as required in the specific server standards document.
2. Security-related events must be reported by Authorized Users to Information Technology Administrator, who review Logs and report incidents to IT Manager department. Corrective measures are prescribed as needed.
Security-related events include, but are not limited to:
a. Port scan attacks
b. Evidence of unauthorized access to privileged accounts or data
c. Anomalous occurrences that are not related to specific applications on the Host

Compliance
1. Audits must be performed on a regular basis by authorized parties within the Company.
2. Audits must be managed by Compliance department or Information Technology personnel, in accordance with the Audit Policy documentation.
3. Every effort will be made to prevent audits from causing operational failures or disruptions.

  1.  Enforcement.
Any Authorized User found to be in violation of this policy will be considered an Unauthorized User, and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use Policy.
“De-Militarized Zone” Network Equipment Policy

  1. Purpose.
Company information technology resources that connect directly to the Internet are considered part of a "De-Militarized zone" (DMZ) on the Company Information Technology Network. These resources are particularly vulnerable to attack since they are directly accessible from the Internet.
The purpose of this policy is to articulate standards that govern the use of all Company Information Technology Network information technology resources, which are located within a Company DMZ Network. These standards are designed to minimize the exposure of the Company from the loss of sensitive or confidential data, Intellectual Property, damage to the Company’s public image, etc., which may result from Unauthorized Use of Company Information Technology Network information technology resources.

The policy defines the following standards:
• Operational Group responsibility
• Secure configuration requirements
• Operational requirements
• Change control requirements

  1. Scope.
All Company Information Technology Network information technology resources deployed in a DMZ owned or operated by the Company, including but not limited to servers, Routers, or switches, must be operated in accord with this policy. Additionally, all information technology resources registered in any Domain Name System (DNS) domain owned by the Company are subject to this policy. Any devices outsourced or hosted at third-party service providers, if said information technology resources reside in the "domain.co.id" domain or appear to be owned by the Company, are also subject to this policy.
All new Company Information Technology Network equipment that is subject to this policy must be configured according to the applicable configuration documents, unless a waiver is obtained from Company Information Technology personnel. All existing and future Company Information Technology Network equipment deployed on a Company DMZ Network must comply with this policy.
  1. Policy.
Ownership and Responsibilities
Company Information Technology Network equipment and applications within the scope of this policy must be administered by the Information Technology department, and be approved by authorized Information Technology personnel for DMZ-level management of the relevant system, application, or Network access.
The Information Technology Services department is responsible for the following:
1. Documenting equipment in the Company Security Management System, recording at least the following information:
a. Host contacts and location
b. Hardware and Operating System version numbers
c. Main functions and applications
d. Password groups for privileged passwords
2. Assuring that Company Information Technology Network interfaces have appropriate DNS records (minimum of A and PTR records).
3.  Assuring that password groups are maintained in accordance with the Company Password Management System and the Password Policy.
4. Assuring that immediate access to Company Information Technology Network equipment and system Logs is granted to Information Security personnel upon demand, in accordance with the Audit Policy.
5. Assuring that changes to Company Information Technology Network existing equipment and deployment of new equipment comply with the Company Change Management System and comply with the Change Management Policy.
To verify compliance with this policy, Company Information Security personnel periodically perform an audit on DMZ equipment as set forth in the Audit Policy.
General Configuration Policy
All Company Information Technology Network equipment must comply with the following configuration policy:
1. Hardware, Operating Systems, Services and applications must be approved by Company Information Technology personnel, as part of the pre-deployment review phase.
2. Operating System configuration must be done in accord with the secure server and Router installation and configuration standards, as defined in the Server Configuration and Workstation Configuration policy.
3. All Patches and updates recommended by the equipment vendor and Information Technology personnel must be installed. This applies to all Services installed, even though those Services may be temporarily or permanently disabled. Operational Groups must have processes in place to stay current on appropriate Patches and updates.
4. Services and applications not serving business requirements must be disabled.
5. Trust Relationships between systems may only be introduced according to business requirements, must be documented, and must be approved by Company Information Technology personnel.
6. Services and applications not for general access must be restricted by Access Control Lists.
7. Insecure Services or Protocols (as determined by Company Information Technology personnel) must be replaced with more secure equivalents whenever such exist.
8. Remote administration must be performed over Secure Channels (e.g. encrypted Network connections using Secure Shell) or Console Access independent from a DMZ Network.
9. All server content updates must occur over Secure Channels.
10. Security-related events must be logged and audit trails saved to Logs approved by Company Information Technolgy personnel. Security-related events include, but are not limited to, the following:
a. User login failures
b. Failure to obtain privileged access
c. Access policy violations
New Company Information Technology Network Installations and Change Management Procedures
All new installations and changes to the configuration of existing Company Information Technology Network equipment and applications must comply with the following standards:
1. New installations must be done in compliance with the DMZ Equipment Deployment Process.
2. Configuration changes must comply with the Company Change Management Policy.
3. Information Security personnel must be notified to perform system or application audits prior to the deployment of new Services.
4. Information Security personnel must be engaged, directly or in accordance with the Company Change Management System, to approve all new deployments and configuration changes.
Company Information Technology Network Equipment Outsourced to External Service Providers
The responsibility for the Security of Company Information Technology Network information technology resources deployed by external service providers must be articulated in the contract with the service provider and must include Security contacts. Escalation procedures must also be documented. Contracting Company departments are responsible for the third-party organization’s compliance with this policy.

  1. Enforcement.
Any Authorized User found to be in violation of this policy will be considered an Unauthorized User, and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use Policy.



Router Security Policy

  1. Purpose.
This document describes a required minimal Security configuration for all Routers and switches connected to the Company Information Technology Network or used in a production capacity on behalf of the Company.

  1. Scope.
All Network infrastructure devices connected to the Company Information Technology Network are subject to this policy.

  1. Policy.
Every Router must meet the following configuration standards:
1. The Router must have no local user accounts configured. Routers must use the Terminal Access Controller Access Control System (TACACS+) Protocol for User Authentication.
2. The “enable” and “secret” passwords on the Router must be kept in a secure encrypted form. The Router must have the “enable” and “secret” passwords set to the current production Router passwords provided by the Information Technology Services department.
3. The following are prohibited:
a. IP directed broadcasts
b. Incoming packets at the Router sourced with invalid addresses (e.g. RFC1918 addresses)
c. TCP small Services
d. UDP small Services
e. All source Routing
f. All web Services running on Router
4. Company standardized Simple Network Messaging Protocol (SNMP) community strings must be used.
5. Information Technology Services has the authority to, and will add, rules to the Access Control List as business needs arise.
6. The Router must be included in the Company Security Management System with a designated point of contact.
7. Each Router must have the following statement posted in clear view:
"UNAUTHORIZED ACCESS TO THIS NETWORK DEVICE IS PROHIBITED. Users must have explicit permission from Company’s Information Security to access or configure this device. All activities performed on this device may be logged, and violations of this policy may result in disciplinary action, and may be reported to law enforcement. Authorized Users who utilize this device have no right to privacy.

  1. Enforcement.
Any Authorized User found to be in violation of this policy will be considered an Unauthorized User, and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use Policy.
Wireless Communication Policy

  1. Purpose.
This policy defines the standards that govern the use of wireless communication equipment to access the Company Information Technology Network.

  1. Scope.
This policy covers all wireless data communication devices, including, but not limited to, personal computers, cellular phones, and wireless access points (WAPs) connected to the Company Information Technology Network. This includes any form of wireless communication device capable of transmitting packet data. Wireless devices or Networks that do not connect to the Company Information Technology Network are not subject to this policy.

  1. Policy.
Use of Wireless Equipment
Authorized Users may only access the Company Information Technology Network via wireless systems that meet the criteria set forth in this policy, unless they have been granted a written waiver by Information Technology personnel.
Corporate WIFI use for the Staff only, and for the guess or visitor is connected to Service Set Identifier (SSID) Company public WIFI.
Register Access Points and Cards
All WAPs and base stations connected to the Company Information Technology Network must be registered with and approved by Information Technology personnel. Use of these devices by Authorized Users subjects the devices to periodic penetration tests and audits by Information Security. All Wireless Network interface cards used in resources owned by the Company must be registered with the Information Technology Services department.
Approved Technology
All wireless Local Area Network (LAN) access must use vendor products and Security configurations approved by Information Technology personnel before being connected to the Company Information Technology Network.

  1.  Enforcement.
Any Authorized User found to be in violation of this policy will be considered an Unauthorized User, and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use Policy.



Change Management Policy

  1. Purpose.
This policy describes a systematic process to document and manage changes to the Company Information Technology Network in order to permit effective planning by the Company Information Technology Services to serve the Company user-base.
  1. Scope.
This policy applies to all Authorized Users that install, maintain, or operate Company information technology resources, including, but not limited to: computer Hardware, Software, and Networking devices.
  1. Policy.
Any change to a Company Information Technology Network information technology resource is subject to this policy, and must be performed in compliance with the Company’s Change Management Procedure.
All changes affecting Company Information Technology Network computer-based environmental facilities, including but not limited to electricity, and alarms, must be reported to or coordinated with the Information Technology department.
A formal written change request must be submitted to the Information Technology department for all changes, both scheduled and unscheduled.
All scheduled change requests and supportive documentation must be submitted in compliance with the Change Management Procedure. The request will then be reviewed by the Management, and a decision will be made whether to allow or delay the request.
The Management may deny a scheduled or unscheduled change for reasons that include, but are not limited to, the following: inadequate planning, inadequate reversion plans, negative impact of change timing on a key business process, or inadequate resource availability.
Customer notification must be completed for each scheduled or unscheduled change, in compliance with the Change Management Procedure documentation.
A Change Review must be completed for each change to the Company Information Technology Network, whether scheduled or unscheduled, successful or not.
A Change Management Log must be maintained for all changes. The Log must contain (but is not limited to):
• Date of submission
• Requestor of change
• Date of change
• Implementer of change
• Nature of the change
• Results of the change
  1. Enforcement.
Any Authorized User found to be in violation of this policy will be considered an Unauthorized User, and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use Policy.
Information Security Audit Policy

  1. Purpose.
Information Technology personnel utilize various methods to perform electronic scans of the Company’s Networks and Firewalls, or on any system connected to the Company Information Technology Network.
Information Security personnel are authorized to conduct audits to:
• Ensure integrity, confidentiality and availability of information and resources
• Investigate possible Security incidents
• Ensure compliance to Company Information Technology Policies and Procedures documentation
• Monitor Authorized User or system activity where appropriate
  1. Scope.
This policy covers all computer and communication devices owned or operated by the Company. This policy also covers any computer and communications device that are connected to the Company Information Technology Network, but which may not be owned or operated by the Company. Information Security personnel will not perform Denial of Service or other disruptive activities.

  1. Policy.
Authorization to Audit
Only Information Technology personnel or other specifically authorized parties may audit devices that are owned by the Company or are connected to the Company Information Technology Network. Third-party organizations may only perform audits with the explicit written permission of the Information Technology department.
Access
Information Technology personnel shall be granted access to the following in order to effectively perform audits:
• User level or system level access to any computing or communications device
• Access to information (electronic, hardcopy, etc.) that may be produced, transmitted or stored on the Company Information Technology Network.
•  Access to work areas
• Access to interactively monitor and Log traffic on the Company Information Technology Network

  1. Enforcement.
Any Authorized User found to be in violation of this policy will be considered an Unauthorized User, and as such are subject to disciplinary action pursuant with the Enforcement section of the Unauthorized Use Policy.


Linux Software RAID

Introduction The main goals of using redundant arrays of inexpensive disks (RAID) are to improve disk data performance and provide data re...