IS SECURITY &
RISK MANAGEMENT
CHAPTER 9 & 10
Oleh Kelompok 5 :
Derrick Lee – 1901809453
Kevin Tee – 1901809440
Nayaka Suranadi Tama – 1901809535
A BLUEPRINT FOR SECURITY
AGENDA :
1. Risk in the Development Lifecycle
2. Security Architecture
3. Patterns and Baselines
4. Architectural Risk Analysis
Risk in the Development Lifecycle
Analysis Workflow
The process for defining security requirements should begin with a security
risk profile of the proposed application/system.
The security architecture risk analysis process should be initiated as part of
the application design process and describes the steps included in the
architecture workflow.
Risk in the Development Lifecycle
Several points in a system’s lifecycle will
require guidance from the enterprise
information security architecture (EISA),
including the following:
• Design stage – after a new system is
proposed.
• Evaluation stage – after a system is
implemented, but before it goes “live”.
• Re-evaluation stage – anytime a
significant change is made to the
system’s risk profile, or on a regularly
scheduled basis.
• Audit stage – whenever an audit is
performed on a system
Security Architecture
Goal of Security Architecture
To realize a unified vision of information security across the entire business that
can grow and scale over time, several design priorities must be established.
– Provide guidance for tactical security projects
– Facilitate the security policy and process initiatives
– Lead the standardization of risk decisions and technology across the organization
– Better establish security standards for the design of new systems, environments,
and services •
– Establish basic security principles that limit access by default and diversify
protection techniques
– Improve the security of the organization
Security Architecture
Developing an Architecture
The enterprise information security architecture (EISA) facilitates the organization’s ability to satisfy the following
requirements that were set forth in the Information Security Policy:
– Security architecture shall enable the organization and its business units to perform business processes electronically and
deliver secure services to their customers.
– Business requirements and security policies, not the technology itself, should drive the choice of security controls.
– Security levels applied to data and resources shall, at a minimum, be commensurate with their business value and sufficient
to contain risk to an acceptable level.
– Security architecture shall be based on industry-wide, open standards, where possible, and accommodate needs for varying
levels of security.
– Security is a critical component of individual business unit and organization systems interoperability.
– Information systems security will be built into systems from their inception rather than “bolted on” after system
implementation.
– To achieve the benefits of an enterprise-standards-based architecture, all information technology investments shall conform
to the established EISA that is designed to ensure the protection and interoperability of information technologies across the
organization.
Architecture hierachy
Security Architecture
Security Architecture Principles
The following are foundational security principles that should
influence the development of the architecture and patterns, as well
as their implementations:
– Should be in alignment with security policies.
– Security policies should drive the selection and implementation of
security controls (process or technical).
– Should be risk-based.
PATTERNS AND BASELINES
Services (Payload) Traffic
Services traffic is business data and communications exchanged between a service
and its intended business clients, directly related to fulfilling the business purpose
for which the service was created.
Management Traffic
Management traffic is any service that makes direct contact to another asset
(which becomes the “managed resource”), either to retrieve or interface with
the configuration and status of hardware components, the core operating
system, features of user interfaces to the OS, or the business application,
sometimes taking subsequent action to maintain or change configurations.
PATTERNS AND BASELINES
Infrastructure Common Services
Common services are services used by multiple applications, data flows, zones, and tiers.
They are focused on application use (as opposed to management use). Examples
may be date/time synchronization, authentication and directory services, network
address assignment, and network name resolution.
Transitive Risk Considerations
As portions of infrastructure are designed, built, or redesigned, the risk imposed by neighboring
resources and communicating resources needs to be considered.
Three primary reasons to separate resources using security zones are as follows:
1. Outside risk (cannot accept risk) – the content of the zone is subject to external risk and
must be protected.
2. Inside risk (generates risk to others) – the content of the zone poses additional risk to the
environment and therefore requires separation.
3. Nonsecurity related – business requirements dictate isolation of the environment (for
availability, throughput, and so on).
ARCHITECTURAL RISK ANALYSIS
Detailed Risk Analysis Workflow
The workflow lays out the approach to applying the security
architecture to a system or environment’s lifecycle and the
progression of the workflow.
This workflow represents the confluence of tools and
techniques within a security architecture with existing
operational evaluation and planning activities, including
portions of other risk assessment processes and
development systems such as a typical Information Security
Risk Management Program and SDLC.
Security Architecture Risk Analysis
Workflow
BUILDING A PROGRAM FROM SCRATCH
AGENDA :
1. Designing a Risk Program
2. Prerequisites for a Risk Management
Program
3. Risk at the Enterprise Level
4. Linking the Program Components
5. Program Roadmap
Designing a Risk Program
Program Goals
The following are the essential steps for a young security risk management
program:
1. Establish an asset inventory
2. Define your risk scales
3. Profile your environments (sensitivity)
4. Define a workflow for assessing vulnerabilities
Designing a Risk Program
Comparing the Models
Risk management is complex topic including many activities that touch on
all aspects of any business, so you will likely find that each of the popular
industry frameworks is better suited for particular situations.
1. NIST
2. OCTAVE Allegro
3. FAIR
4. FRAAP
Prerequisites for a Risk
Management Program
• Security policies and standards
• Information resources inventory
• Security liaisons
• Common risk formula
• Enterprise risk committee
• Mapping of risk domains to business objectives
• Other security processes tied to risk
• Risk and exception tracking system
Risk at the Enterprise Level
Before you can even hope to tackle risk management at an enterprise level or integrate your security
risk management program into an enterprise level view, you need to convince the organization of the
value of a common risk formula.
Enterprise Risk Committee
In most organizations, the Enterprise Risk Committee is made up of senior management or their representatives.
All the different functions should be represented, including information security, legal, compliance, HR,
operations, finance, and vendor management. Typical characteristics for an enterprise risk committee include the
following:
– Looks at risks across the entire organization
– Most senior management levels
– Information security is just one member
– Only the highest level risks are reported
– Often systemic or thematic risks are highlighted
– Usually reports risks to the board of directors
Risk at the Enterprise Level
Mapping Risk Domains to Business Objectives
A risk domain is a high-level grouping of risk areas that is generally tied to an
overall business goal for the organization. For example, a business goal might
be to increase the efficiency of service/product delivery to customers. Some
possible business objectives that you might use to define your risk domains are
as follows:
– Make money (maintain a profit margin)
– Don’t break any laws/regulations (keep regulators happy)
– Stay ahead of our competition
– Grow into new markets/diversify your revenue
– Increase/protect the brand value
– Deliver your products and services as expected
– Maintain operational excellence
Risk at the Enterprise Level
Examples of Risk Areas
Within the scope of technology, there are several key risk areas
(some examples are listed) that can be used to categorize similar
risk types. These groupings of risks help us to identify similar risks
in our modeling exercises and for reporting purposes.
• Asset management
• Business continuity
• Change management
• Vendors and outsourcing
• Privacy and data protection
• Physical and environmental
Linking the Program Components
Tying Other Security Processes to Risk
Alignment amongst all the various information security activities and functions should have obvious value, but the
best way to link these individual activities together isn’t always as clear.
These are just some of the activities that should feed information into the risk management program by identifying potential
risk exposures:
– Vulnerability scanning
– Incident notification and response
– Application code reviews
– Architectural and design reviews
– Compliance to standards review
– Security event monitoring
– Internal audit reviews
Program Roadmap
Risk and Exception Tracking System
This doesn’t have to be anything particularly complicated to start, but it
does need to capture basic analysis information and mitigation plans.
There are several commercial products in the Governance, Compliance,
and Risk (GRC) space to fit this need, but use of these products is not
necessary for success.
• document risk decisions
• capture reasons for risk rating
• document compensating controls
• provide tracking of mitigation plans
Program Roadmap
CASE STUDY
PT. POS INDONESIA
STUDI KASUS PADA PT. POS INDONESIA
PT POS Indonesia (Persero) adalah Badan Usaha Milik Negara yang bergerak dalam jasa pengiriman barang serta dokumen
yang telah berdiri sejak tahun 1946. Sejak dibentuk, PT POS INDONESIA (Persero) hanya melakukan pengiriman dalam
wilayah Indonesia saja, kemudian wilayah jangkauannya diperluas hingga internasional. Inovasi baru dengan melibatkan
keberadaan teknologi informasi diciptakan karena perbaikan pelayanan serta munculnya banyak pesaing. Salah satu jenis
teknologi yang sedang dimanfaatkan oleh PT. POS Indonesia adalah penggunaan web dan internet untuk meningkatkan
layanan pengiriman barang dan surat ke luar negeri. Ini dibuktikan salah satunya dengan keberadaan EMS (Express Mail
Service) berbasis web.
Akan tetapi keberadaan teknologi informasi sendiri akan menimbulkan masalah baru jika pengelolaannya hanya dipandang
sebagai aktifitas penyediaan perangkat lunak/ keras untuk kebutuhan otomatisasi. Pandangan demikian menciptakan
kesenjangan berupa redudansi data, aplikasi, paltform teknologi dan belanja TI yang berlebihan seiring dengan
perkembangan teknologi dan organisasi itu sendiri. Intinya adalah diperlukan suatu keselarasan (alignment) antara TI dengan
bisnis.
Arsitektur enterprise merupakan tool untuk mengelola TI dalam organisasi yang dapat bertujuan untuk membuat suatu
standarisasi dan panduan untuk mencapai objektif organisasi. Dalam mengimplementasikan arsitektur enterprise pada suatu
organisasi aspek-aspek yang ada harus selalu menjadi fokus perhatian. Pada tulisan kali ini aspek yang akan ditinjau adalah
aspek penyelarasan (alignment) dan integrasi (integration)dari berbagi informasi.
CASE STUDY
PT. POS INDONESIA
Perumusan masalah dalam studi kasus ini adalah sebagai berikut:
– Faktor-faktor risiko (risk factor) apa yang timbul pada penerapan arsitektur enterprise di PT. POS Indonesia.
– Bagaimana melakukan analisis arsitektur enterprise dan pengelolaan risiko dari aspek penyelarasan dan
integrasi.
– Bagaimana strategi yang harus dilakukan dalam meminimalisir risiko.
Strategi Bisnis PT. POS
– Pengembangan sumber daya manusia untuk meningkatkan performansi dengan dasar kultur kerja yang
sehat
– Meningkatkan produktivitas dalam rangka peningkatan efisiensi dan efektifitas biaya
– Meningkatkan kualitas layanan untuk mendapatkan kepercayaan pelanggan
– Meningkatkan pendapatan untuk mendukung keberlangsungan perusahaan
– Perbaikan berkelanjutan
CASE STUDY PT. POS INDONESIA
Area Fungsional Proses Bisnis
Keuangan 1. Akuntansi umum
- Pengelolaan asser dan kewajiban korporasi
- Pengelolaan pajak yang dikenakan terhadap perusahaan
2. Pengelolaan keuangan
- Pengelolaan keuangan harian perusahaan
-Pengawasan transaksi untuk mengoptimalkan peningkatan marjin keuntungan
- Pelaporan keuangan
3. Perencanaan anggaran
[Link] biaya, diantaranya pengelolaan pembayaran hutang piutang perusahaan
Pemasaran 1. Pengelolaan pelanggan
- Pengidentifikasi potensi pelanggan
- Pendefinisian kebutuhan dan keinginan pelanggan
2. Pengelolaan pemasaran
- Pengidentifikasian kebutuhan pasar
- Pengemasan produk dan jasa supaya menarik pelanggan
- Pengelolaan transaksi pembelian dan penjualan
3. Pengelolaan promosi
- Pengelolaan promosi dan periklanan perusahaan
- Pengelolaan kerjasama dalam rangka memperluas pemasaran
SDM (Sumber Daya Manusia) 1. Rekrutmen personil
- Penentuan kebutuhan pegawai baru
- Pengelolaan persiapan dan seleksi pegawai baru
2. Pengelolaan personil
- Pengelolaan pelatihan, pengembangan dan penilaian prestasi pegawai
- Pengelolaan promosi,penetapan, pemindahan dan pemberhentian pegawai
- Pembayaran gaji, honor dan kontrak pegawai pada periode tertentu
R&D 1. Marketting riset
- Penelitian pangsa pasar
- Pengembangan teknologi informasi perusahaan
2. Riset dan inovasi layanan
- Penelitian prilaku organisasi
- Pengembangan inovasi produk dan jasa
Operasional 1. Pengelolaan transaksi penerimaan
2. Pengelolaan transaksi pengiriman
CASE STUDY PT. POS INDONESIA
Kategori Risiko Faktor-Faktor Penyebab Risiko
Struktur dan strategi - Kurangnya dukungan manajemen level atas
manajemen - Komunikasi yang tidak efektif
- Kurangnya penghargaan
- Kurangnya persiapam struktur kendali manajemen
Perbedaan level - Kurang ahlinya pegawai internal
keahlian - Kurangnya pelatihan dan re-skilling
- Kurangnya pengetahuan tentang bisnis dan teknologi
- Kegagalan dalam menggabungkan keahlian internal dan external expertise secara efektif
- Kurangnya kemampuan untuk merekrut dan mempertahankan pengembang sistem ERP yang berkualitas
Aliansi dengan - Kegagalan dalam mengikuti enterprise-wide design yang mendukung integrasi data
organisasi - Kegagalan dalam mendesain ulang proses bisnis
Perancangan sistem - Kurangnya integrasi
- Pengadaan software dan hardware tidak mengikuti spesifikasi pada standarisasi
Perencanaan dan - Tidak dapat menghindari technological bottlenecks
integrasi teknologi - Mencoba untuk menjembatani aplikasi yang telah ada
Keterlibatan - Kurangnya pelatihan pada pengguna akhir
pengguna dan - Komunikasi yang kurang efektif
pelatihan - Kurangnya komitmen dari pelanggan terhadap manajemen proyek dan aktifitas proyek
- Kurangya sensitivitas terhadap resistansi pengguna
- Kegagalan pelaporan
CASE STUDY
PT. POS INDONESIA
Strategi Meminimalkan Risiko
– Untuk meminimalkan risiko-risiko tersebut, PT. POS Indonesia perlu melakukan pemeliharaan arsitektur enterprise secara periodik dengan membentuk sebuah tim yang
berada dibawah tanggung jawab pihak manajemen. Pemeliharaan ini dengan cara melakukan penilaian penyelarasan dan pengintegrasian terhadap kemungkinan
perubahan praktek bisnis, kondisi keuangan, perubahan teknologi dan kemungkinan modernisasi proyek. Karena, apabila tidak dilakukan pemeliharaan dalam arti tidak
dijaga kerelevanannya, bisa jadi keberadaan arsitektur enterprise sendiri dapat menghambat organisasi dalam mencapai tujuannya.
– Berikut ini beberapa strategi yang dapat dilakukan [Link] dalam meminimalkan risiko-risiko yang mungkin muncul dalam penerapan arsitektur enterprise :
– Menyelaraskan risiko keinginan dan strategi, mempertimbangkan risiko dalam mengevaluasi alternatif yang strategis, menentukan objek-objek yang terkait dan
mengembangkan mekanisme untuk mengelola risiko terkait.
– Menyediakan aturan untuk mengidentifikasi untuk memilih dan mengidentifikasi pencegahan adanya risiko, mengurangi, membagi dan menerima risiko.
– Mengurangi operasional dan kerugian tidak terduga
– Meraih peluang dengan mempertimbangkan jangkauan kejadian yang potensial, memposisikan pihak manajemen untuk mengidentifikasi dan proaktif dalam merealisasikan
peluang
– Pemeliharaan arsitektur enterprise dalam rangka meningkatkan organisasi
– Memastikan arahan proses dan bisnis mencerminkan operasi
– Memperbaiki penyebaran modal, dan mengizinkan pihak manajemen untuk memprediksi semua kebutuhan modal yang efektif dan mengubah alokasi modal.
– Memastikan arsitektur yang saat ini mencerminkan evolusi sistem
– Evaluasi dasar hukum kebutuhan pemeliharaan sistem terhadap perencanaan sekuensial
– Pemeliharaan perencanaan sekuensial sebagai perencanaan program terintegrasi
CASE STUDY
PT. POS INDONESIA
KESIMPULAN
– Arsitektur enterprise merupakan sebuah mekanisme yang memfasilitasi agen perubahan yang secara
sistematis berkelanjutan guna menyelaraskan investasi teknologi dan proyek dengan apa yang
diinginkan oleh pihak manajemen. Dalam menerapkan arsitektur enterprise di sebuah perusahaan
perlu diidentifikasi faktor-faktor risiko yang mungkin timbul sebagai bentuk pemeliharaan. Dengan
pemeliharaan arsitektur enterprise secara berkala maka akan mengurangi risiko kegagalan dalam
mewujudkan tujuan organisasi.
– Pada penulisan studi kasus ini telah dilakukan identifikasi risiko dan beberapa strategi
meminimalisirnya dengan objek PT. POS Indonesia. Proses yang dikaji hanya sebatas perencanaan yang
menyinggung aspek penyelarasan dan intergrasi dalam penerapan arsitektur enterprise. Tetapi tidak
mengkaji lebih jauh mengenai metodologi dan kerangka kerja manajemen risiko dalam arsitektur
enterprise itu sendiri.
