Instruction Manual Promotional Media - Assignment Example

 Instruction Manual Promotional Media I. Data Flow This company advises on, and designs, promotional media – branding, print, Web, TV video etc. 

Projects involve the creation of documents and media files, mainly in proprietary format; e.g. advertisement copy, scripts for video shoots, campaign schedules, artwork etc., that must be regularly exchanged in digital format with clients for comment and approval. 

Documents need to be held and transferred securely. The office LAN comprises Windows XP/Vista and Mac workstations, managed by a Windows Server 2008 and has hot-desk provision for laptops. Without dedicated networks to clients, and because there would be unacceptable security risks in managing client VPN access to the office LAN, it has been proposed that all networked services outside the office LAN will be managed on a separate machine running a Linux (or Ix) OS. This would be networked to the LAN. It has not yet been decided whether or not there is a requirement for a separate database server to be added to the network, however this will be provided for. a. Internal LAN 1. Will have reliable single-thread performance, maximum I/O connectivity, maximum I/O bandwidth, and have reliability allowing service while system runs. 2. Objects within the AD recognizes transitive trusts/forests. In this case, this represents individual functions like a hierarchy. The company’s site represents the structure of the company and will maximize the flow of data. The company, for our purposes, has a domain with an OU within it. b. External LAN 1. Numerical data is stored in flat ASCII files 2. Portable data and text data files will make process easier 3. “Streaming” will process data until there is no more input 4. Mainframe "blocking" will occur II. Project Work a. Users and Groups The term “users” means application servers, mail servers, web servers, or individuals. “Groups” are the roles of users. 1. Configuring Users and Passwords for Ix a. Set root password, create regular user, and password strength. 2. Choosing Secure Passwords a. Passwords should be: a mix of letters, numbers, and symbols of upper and lower case; six characters long; not associated with anything person; not a common word; different from other passwords; specific to your account; and not written down. 3. Set the Root Password for Ix a. Enter password for root user. 0 b. Re-enter password to confirm (passwords must match). 1 *N.B.: If you change the root password, your work may be lost, which you will have to recreate on a new installed server. Never work in root unless you must configure the server. 4. Create a Regular User Account for Ix a. Enter a user name and full name for the account. 0 b. Enter password, re-enter, and confirm password. b. Sensitive Data The problems with encrypting all stored data is difficult to impossible. Therefore, certain measures must be taken in order to ensure data security. 1. Storage a. Network—Files are protected by ciphers. In environments where there are many people on a server, methods of encryption are preferable. On the Win system, you must configure the fileserver. Within the Win, EFS is used as the default file encryption mechanism. b. Internet—Any transfer of sensitive data must be cryptographically enabled. c.Transfer 1. Network—The most sensitive data on network is encrypted. Firewall technology is one feature of database security. Data-sharing is necessary. 2. Internet—There must be separate encryption for transit and storage. III. Procedures a. Authentication 1. Internal to LAN a. Use the Universal Group model. 2. External to LINUX a. All log-ons cryptographically enabled; permit only three attempts before disabling account temporarily 3. To Database Server a. Authentication allows or deny access. b. Authorization Authorization is the permission allowed someone to access a system. 1. Internal to LAN a. Enables admins to manage users, groups, domain resources, locate resources on domain, to group objects into OUs; enables security and other Group Policies to be dictated 2. External to LINUX “Blocking scheme” is used, while form updates are collected together on the user's workstation without consuming any network or server resources, and are submitted en masse when the SUBMIT tag is selected. 3. To Database Server a. With multi-tier server, create lightweight sessions, allowing database authentification for each user. c. Access Control This is the process of setting up who and who cannot be allowed in the system. 1. Internal to LAN a. AD via LDAP b. Use Universal Group model with specific groupings 1. Local groups 2. Built-in grups 3. Special Groups 4. Domain Local Groups a. Membership can be outside domain 5. Global Groups a. Control access restricted to global and domain users 6. Universal Groups a. Includes users from any domain *N.B.: Groups can be placed within other groups. c. Available groups 1. Admin 2. Print Operators 3. Backup Operators 2. External to LINUX a. Immediately change root password from default. 3. To Database Server a. Managed remotely via VPN, managed by network server. *N.B.: Be clear onto what it is that users are logging onto. IV. Web Access a. Integration A suitably configured web server (such as Apache) where form processors are integrated into the web server can handle processing quickly and efficiently. b. Configuration 1. Maximize security by eliminating flaws/vulnerabilities within the system by grouping database updates together; use “block mode” for Win. 2. For Ix, install and restart. Go through a series of screens to configure different elements of the system. Once installation is completed, select desired tools from System of gnome Control Center. a. Middle-click anywhere on the screen except the window to open a virtual terminal for troubleshooting. b. Select the options to configure. By default, all options are configured except X configuration. You must configure Users and Electronic Mail. c. Most users should configure all options. However, if you decide not to, you can configure from the desktop. V. Secure Messaging System a. Integration 1. Group updates together. 2. Develop policies for mobile log-ons.Uses For Cryptography 3. Encrypt messages through e-mail using PKI/cyphertext. b. Configuration 1. In Win, when both explicit and inherited ACEs are applied to an object, explicit ACEs are checked before the inherited ACEs; access is allowed or denied by the explicit even if the obverse is the case by inheritance. 2. In Ix, read permission on directory permits, either “owner,” “group”, or “world.” a. Change content, create, edit, or delete as necessary. b. If desired, execute permission c. Configure a network or dial-up connection for the general set-up for e-mail. d. If all else fails, consult system admin or ISP. VI. System Failure A. Admin appoints recovery agent for encrypted information 1. Results for public key stored in Data Recovery Field a. Only admin and the RA (not junior admins) can decrypt data b. Back-up operators ( below RA’s) require sysadmin approval B. Procedures for Restoration 1. In Win, steps for Recovery Agents: a. logon as domain administrator (as above) onto your local server, b. start -> run -> mmc -> add/remove snap-ins, c. add -> group policy object editor snap-in -> add -> close -> OK, d. computer configuration -> windows settings -> security settings -> public key policies, e. open the encrypting file system folder, f. who is currently enabled as recovery agent on the machine? Is that appropriate? g. use Win help to establish how you would add a recovery agent. 2. In Ix a. Prepare server, download the installer, install, reboot VII. Network Compromise a. Auditing Procedures 1. Have audit policies include the following: account logon events account management directory service access logon events object access policy change privilege use process tracking system events 2. In Win, back-up specific information, restore and manage media, delegate responsibility of archiving and management 3. In Ix, back-up and restoration consists of two command line utilities that combined make for simple and highly configurable backup and restoration - tar and cron. Refer to tldp.org. a. Automating Backup With Tar And Cron In Ix i. Working as root, in your /tmp directory create a new directory called tar-test [mkdir tar_test], with 0755 permissions ii. cd to tar_test and create two new files firstfile.txt and secondfile.txt , iii. use vi to put some text in each file, iv. you now have a file archive called tar_test that you are going to backup with tar, v. create a new directory in /tmp called 'backup', vi. in the /tmp directory execute the following command [tar -cvf backup/tarred tar_test], you are creating a tar archive of tar_test called tarred in the folder backup, vii. of course IRL you wouldn't do anything so stupid as to backup to the same disc - it would all go to removable media or, better still, a central backup server, viii. use ls to see that tarred exists in the backup archive, ix. now simulate a catastrophic loss of data [rm -r tar_test], x. and restore [tar -xf backup/tarred], xi. use 'ls' and 'less' to see that everything is restored, xii. now use vi to edit one of the textfiles and change some of the text, xiii. from the /tmp directory run the following [tar -uvf backup/tarred tar_test], which should update the backed-up archive for the changes made to the textfile, xiv. again, remove the tar_test directory and its contents and restore using tar as above, your backup should have picked up the changes you made to the textfile, xv. we're now going to automate the process by creating a perl script, create a new file in the /tmp directory [touch backup.pl], xvi. write the following into the file using a text editor: xvii. #!/usr/bin/perl xviii. `tar -uvf backup/tarred tar_test`; xix. exit 0; xx. give the file 0755 permissions [chmod 0755 backup.pl] (actually, since you are working as root 0700 permmissions would be better, but you may want to permit utilities not running as root to execute your new perl script, so we'll leave it as 0755 for the time being), xxi. test that it works by, as above, editing one of the text files and then executing the script from the /tmp directory [./backup.pl], xxii. now all we need to fully automate the backup process is to instruct crond to execute the script, say every ten minutes, xxiii. check to see what cron jobs already exist for the root user [crontab -l], xxiv. create [touch] a texfile called 'backupauto', xxv. insert the following, precisely, into backupauto: xxvi. 0,10,20,30,40,50 * * * * /tmp/backup.pl which will give instructions to crond to run the backup script every ten minutes, *N.B.: the instructions are space delimited, so there should be no gaps after each of the commas, but gaps around each of the stars. Also, you _must_ have a line ending after the line above, so carriage return to the next line when editing with vi. xxvii. give the instructions to crontab: [crontab backupauto], (alternatively, you could have edited the crontab file directly using the command [crontab -e]), xxviii. check to see that crontab has the message [crontab -l], xxix. edit one of the archive textfiles and wait for twenty minutes or so, xxx. delete the archive and restore from backup to see if the automated instructions are backing up on schedule. b. Using The Audit And Backup Utilities In Win a. Logon to your virtual server as a domain administrator, b. install the backup utility [start - admin tools - server manager - add features - windows server backup] c. Switch to the OSASS DC, d. Active Directory Users and Computers - view - enable advanced features, e. on your OU - right click - properties - security - advanced - auditing (if you haven't created an OU, do the same for your computer), f. first, set some general audit policies that any write activity should be recorded, g. add - write authenticated users - check names - ok - apply onto - Descendant User Objects - select 'write all', h. ok - ok to close all dialogue boxes, i. logoff the OSASS DC, log onto your virtual server as an unprivileged domain user, j. create a text file and input some text, k. set the audit properties on the new text file to read both success and failure for access to it. l. edit the textfile in some way (this should now be logged), m. logoff/logon as domain admin, n. Use the local event viewer to view the security log, o. Filter the security log for successful owner access to the file. Is the event in the log? p. As admin create another text file, q. logoff/logon as the unprivileged domain user, r. try running the backup utility on the new text file (owned by admin), s. logoff/logon as domain admin, t. Promote the unprivileged domain user to a backup operator (add to the backup operator group), u. logoff/logon as the new backup operator, v. Again, use the backup utility to try backing up the text file owned by admin, VIII. Security Policy General operating systems that may be used flexibly for a wide variety of purposes usually require security features to be configured specific to the purposes for which they are to be used - file archiving, mail transport and storage, database administration etc. Until very recently most servers were configured for a variety of applications, but with the growing use of virtualisation, it is now convenient and economic to manage each server instance for a specific purpose and by doing so enhance security. Security Policy Formation is about formally writing down how you are going to address security issues relating to the information infrastructure, which you have been tasked to consider. This is the rationale why this process should be formalised: i. you may forget to consider something unless you create a checklist for yourself, or you may forget what you've done later or you may need to inform others, perhaps junior admin staff, what you've done and how you've done it, ii. your list can be audited and, possibly, improved by others, either internal to the organisation or an outside consultant, iii. you are not alone - almost certainly others before you have met precisely the same situation and worked out their own 'ideal' lists and these may be available (in an open-source way) for you to check against your own policy and help you improve it, and iv. you may (in fact you should) be forced to formalise the policy you are to implement by line managers in your organisation - so that they would have a policy in place in case you were to leave or become incapacitated. This is best practice. For all it is often legally necessary to make reasonable efforts to ensure data security, which often means meeting some published standard. Failure to do that can make national headlines! Also, there are potentially many hidden benefits, for example: there is a paper trail in the event of questions pertaining to due diligence, policy documents will have been reviewed and agreed by senior management, so that implementation can appear to derive directly from senior management and not solely at the whim of the IT department, in a large organisation, policy documents ensure consistant application throughout the organisation and from one timeframe to the next. The following factors provide a minimum framework against which security policies must be designed: i. methods of authentication, ii. the privacy and integrity of data in storage and in transit, iii. access control, iv. non-repudiation of transactions, v. appropriate cryptographic techniques, vi. managing certificates, vii. patch management, viii. the identification of potential risks and their associated costs, ix. procedures for the backing-up and the restoration of data, x. system (OS and application server) configuration, xi. establishing a security task schedule, xii. delegating responsibility for, or automating, security management tasks, But there are many other factors to be considered, some of which more properly fall under the heading of network security. For example: Acceptable Use Policy, Dial-in Access Policy, e-Mail Policy, Password Protection Policy, Remote Access Policy a. Creating a Win Security Policy i. server manager - run SCW - the SCW wizard is designed to enable services and open ports required for the server roles and client features required, ii. create a new policy - but note that you can apply an already existing one! - when would you want to do that? iii. view configuration database - seems to provide a very long checklist! iv. select File Server and keep any other selections as they are - why do you think they have been automatically selected? Why is time synchronisation important? v. in the option for administration leave the defaults selected, but read through the other options, vi. read through the default server configuration - would you have known to edit all the services and dependencies in this way? vii. skip firewall and registry (the registry section is designed to configure protocols, which helps fix vulnerabilities due to legacy systems), viii. select audit successful and unsuccessful activities - Why? ix. call the policy vhXXfileserver1 and save to the default location, x. view your new policy, These changes are intended to make the server much more secure than the default, given its particular role. Are you confident that the server will now be secure? What if the server role were to change in the future? xi. APPLY LATER and exit. a. Confidentiality - ensuring that data is only available to authorised and privileged users (the principal of least privilege should apply) [one machine only need be configured for security) b.Integrity - ensuring that information cannot be modified or corrupted, 1. Includes Operation System hardening c.Authentication - ensuring that requests for data are genuinely from the user from whom they claim to come, [Fortunately there is a wizard to help out, called the Security Configuration Wizard (SCW) for Win.] d.Availability - ensuring the availability of data services, not simply protecting against DOS or DDOS attacks b. The following must also be considered in developing a specialized security policy: IX. External Network: firewalls, SSL, SSH, VPN, X. Internal Network: domain configuration, SSL, IPSec, XI. Host: OS services configuration, patch management, XII. Application: application server configuration, coding for security, XIII. Data: encryption for storage, access control, XIV. User: training XV. Physical: physical access restrictions a. In Ix, label mechanism mandatory; privilege may be suballocated. c. Other policies must be put in place for local control: Software restriction policies: - prevents unwanted software from running, User Account policies: - password policy, account lockout policy, kerberos policy, Local policies: - audit, user rights assignment, security options, System services: - start-up settings, Restricted Groups: - membership, Registry: - key settings, File system: - security, Public key: certificate authorities, data recovery agents, IP security - e.g. encryption. IX. Maintenance Management Policy A. Open a virtual terminal for troubleshooting in Ix 1. Partitions created by some versions of Windows are incompatible with the install program. If an error dialog displays, asking if you want to create a new partition table, select No and exit the install program if you want to keep your existing partitions. a. Backup all data on all partitions. b. Start your system with boot disk. 0 c. When the install program starts, press Alt-Ctrl-2 to start a virtual terminal. d. Use the parted utility to create new partitions. *N.B. for Ix: The root user has the ability to do anything on the system - edit and delete all files including system files, create other user and group accounts and so on. It is tempting as system administrator to logon as root and to work as root, but that would be a mistake. With root privileges, the slightest typing error can corrupt the system. You should work very carefully as root only to manage system files, maintain user accounts and so on. B. Update Triggers 1. Since threats are always changing, so must countermeasures change and the policies in place to implement them. In her excellent Policy Primer, Michele Guel of the Sans Institute lists the following potential triggers for a change in security policy: technology change, major project rollouts, exceptions tracking process input, regulatory compliance requirements, client request/company internal feedback, editorial: grammar, style, or URL reference changes. X. Other Issues 1. FTP is not enabled for the Linux server. a. To make FTP access to a specific user from a specific location: 1. Install ftp server software (wu-ftp) and configure so certain IPs will be able to access the remote server. REFERENCES Browne, Christopher. 2009. http://linuxfinances.info/info/unix.html. Retrieved 5 May 2009. iWebTool Computer Glossary. 2005-2008. What is System Hardening? http://www.iwebtool.com/what_is_system_hardening.html. Retrieved 5 May 2009. McIlroy, M.D. and J. A. Reeds, 2005. The IX Multilevel-Secure UNIX System. http://www.cs.dartmouth.edu/~doug/IX/. Retrieved 5 May 2009. Read More