UNIVERSITAS MULTI MEDIA NUSANTARA

(UMN)

IF 401 - COMPUTER SECURITY

03. PROGRAM SECURITY

Slamet Aji Pamungkas.

Tangerang, Februai 2023
 KECHILAFAN SATU ORANG SAHAJA
TJUKUP SUDAH MENJEBABKAN
KERUNTUHAN NEGARA

Mayjen TNI Dr. Roebiono Kertopati (1914 - 1984)

B apak Persandian Republik Indonesia
REVIEW: USER AUTHENTICATION

Vulnerability
• Vulnerability web/ application
• Vulnerability OS/ software
Attack • Incomplete Authentication
• Impersonation
• Failed Authentication
Countermeasure
• Strong Authentication.
• Ransomware
• Anti Virus
• Virus
• Anti Spyware
OUTLINE
• Threat
• Cacat Program Menyebabkan Kegagalan
Keamanan.
• Pentingnya SOP keamanan siber sejak
disain sampai dengan implementasi.
• Vulnerability
• Incomplete Mediation.
• Race Condition.
• Time-of-Check to Time-of-Use
• Undocumented Access Point.
• Ineffective Countermeasure
• Penetrate-and-Patch.
• Countermeasure
• Identifying and Classifying Faults.
• Secure Software Design Elements.
• Secure Software Development
Process.
• Testing.
• Defensive Programming.
INTRODUCTION

• Salah satu basis/ dasar komputasi adalah

pemrograman dan coding.

• Perusahaan/ perorangan saat ini banyak

yang membuat program/ aplikasi sendiri,
tapi banyak juga yang membeli aplikasi
jadi.

• Program/ aplikasi mempermudah

pekerjaan sehari-hari, sehingga pengguna
senang dengan aplikasi yang siappakai:
• Spreadsheets, music players, word
processors, browsers, email handlers,
games, simulators, and more.
INTRODUCTION

• Program aplikasi saat ini semakin maju dan kompleks.

• Pengguna kadang-kadang hanya menggunakan program/ aplikasi tanpa
mengetahui secara pasti fiolosofi bagaimana memanfaatkan program/ aplikasi
tersebut.
• Ada saatnya pengguna kurang memahami apakah program yang
mereka gunakan memberikan hasil yang benar?
• Bagaimana jika spreadsheet memberikan hasil yang sedikit meleset?
• Bagaimana jika paket gambar otomatis tidak menyelaraskan objek dengan
tepat?
INTRODUCTION

• Manusia bisa saja melakukan kesalahan saat

menulis program/ aplikasi.
• Cacat program dapat mempengaruhi 2 jenis
implikasi keamanan:
• Permasalahan integritas yang bisa menyebabkan
bahwa program menghasikan sesuatu yang salah
atau tindakan yang merugikan.
• Kemungkinan bahwa kesalahan itu akan
dieksploitasi oleh aktor jahat.
• Program yang benar akan menjadi pendukung
keamanan.
 INTRODUCTION

Hacker juga Saat melakukan analisis ancaman,

memperhatikan kita harus memikirkan setiap hasil
terhadap kelemahan yang mungkin terjadi bukan
yang tampaknya tidak hanya sebagai hasil akhir tetapi
signifikan yang dapat juga sebagai batu loncatan untuk
dieksploitasi untuk mengeksploitasi kerentanan
dampak yang lebih lainnya.
besar.
PROGRAM FLAW LEADS TO SECURITY FAILING

Common programming flaws:

• Logical error.
• Syntax error.
• Exceeding the bounds of an array.
• Storing a string value in a numeric
location.
PROGRAM FLAW LEADS TO SECURITY FAILING
• Ada saatnya programmer terlalu optimis dengan
aplikasi yang dihasilkanya.
• Mereka cenderung bersumsi bahwa:
• Data yang diinput selalu seusai yang
diharapkan.
• Update atau koreksi sudah dilakukan
dengan sangat benar.
• Cukup berpedoman kepada hasil
testing, namun tidak secara kontinyu
mengevaluasi dan memperbaiki
program.
• Dengan asumsi bahwa semua masalah sudah
terselesaikan, programmer tidak melakukan
verifikasi ulang dan menyediakan alternatif
apabila terjadi masalah.
Sebagai contoh, programmer diberi beri
tugas untuk menghitung rata-rata 2 nilai
masukan.
Pemrogram mungkin berasumsi bahwa:
• Kedua nilai tersebut adalah angka.
• Jumlahnya tidak akan melebihi ukuran
memori computer.
• Mereka direpresentasikan dalam format
yang tepat (integer atau floating point).
• Modul akan menerima tepat 2 masukan,
tidak kurang atau tidak lebih.
INCOMPLETE MEDIATION

Melakukan verifikasi bahwa subjek/ pengguna memiliki

Mediation
kewenangan untuk melakukan operasi pada suatu objek.
Terjadi pada saat aplikasi menerima/ memproses data yang
salah.
Example:
Forgetting to ask “Who goes there?” before allowing
the knight across the castle drawbridge is just asking
for trouble.
INCOMPLETE MEDIATION

http://www.somesite.com/subpage/userinput.asp?parm1=(808)555-1212&parm2=2009Jan17

• What would happen? • Possibilities

• 1800Jan01? • The system would fail
• 1800Feb30? catastrophically
• 2048Min32? • The receiving program would
• 1Aardvark2Many? continue to execute but would
generate a very wrong result
• The processing server might have a
default condition

• Data sensitif (nilai parameter) berada dalam kondisi terbuka dan tidak terkendali.
• Nilai data tidak sepenuhnya dimediasi.
INCOMPLETE MEDIATION

http://www.things.com/order.asp?
custID=101&part=555A&qy=20&price=10&ship=boat&shipcost=5&total=205

• This procedure leaves the parameter statement open for malicious tampering

http://www.things.com/order.asp?custID=101&part=555A&qy=20&price=1&ship=boat&shipcost=5&total=25

 From a security perspective, the most serious concern about this flaw was the length of time that it
could have run undetected
RACE CONDITION

2 proses penting dalam suati aplikasi “bersaing “

dalam interval waktu yang sama, dan perlombaan
tersebut mempengaruhi integritas atau kebenaran
Serialization Flaw tugas komputasi.

2 proses dieksekusi secara bersamaan, dan

hasil komputasi bergantung pada urutan
eksekusi instruksi dari proses tersebut.
RACE CONDITION

A Seat available? Yes Book seat

A race condition between 2

processes can cause inconsistent,
undesired, and therefore wrong,
outcomes
Reservation System –
A failure of integrity
B Seat available? Yes Book seat

Time
 TIME TO CHECK TO TIME OF USE (TOCTTOU)
Bayangkan seseorang membeli patung seharga
$100. Pembeli mengeluarkan lima lembar
uang $20 dari dompet, menghitungnya
dengan cermat di depan penjual, dan
meletakkannya di atas meja. Kemudian
penjual berbalik untuk menulis kwitansi. Saat
penjual membelakangi, pembeli mengambil
kembali satu lembar uang $20. Ketika penjual
berbalik, pembeli menyerahkan tumpukan
uang, mengambil kwitansi, dan pergi dengan
membawa patung itu.
• It exploits the delay between the
two actions:
check and use
• Between the time the access was
checked and the time the result of
the check was used, a change
occurred, invalidating the result of
the check
UNDOCUMENTED ACCESS POINT

• Dalam pengembangan dan pengujian program, pemrogram

memerlukan cara untuk mengakses internal modul.
• Pemrogram menginginkan mode debug khusus untuk menguji kondisi.
• Jalur akses seperti ini disebut pintu belakang (back door) atau pintu
jebakan (trap door).
UNDOCUMENTED ACCESS POINT

• Kadang terjadi kasus di mana programmer lupa menghapus entry point

khusus untuk masuk aplikasi sampai dengan aplikasi diimplementasi.
• Atau memang programmer sengaja membiarkan hal tersebut (celah
masuk) sebagai jalan untuk masuk sistem pada saat maintenance/
perawatan system nantinya.
• Programmer terlalu percaya diri bahwa tidak ada seorangpun yang akan
menemukan celah tersebut.
• Celah tersebut pada kenyataanya bisa menjadi pintu masuk penjahat.
SALAMI ATTACK
Serangan salami adalah metode kejahatan
dunia maya yang biasanya digunakan oleh
penyerang atau peretas untuk melakukan
kejahatan, misalnya di sektor keuangan.
Penjahat dunia maya mencuri uang atau
sumber daya dari rekening keuangan di
sistem satu per satu. Serangan ini terjadi
ketika beberapa serangan kecil digabungkan
untuk menghasilkan serangan yang kokoh.
karena kejahatan dunia maya semacam ini,
serangan-serangan ini sering kali tidak
terdeteksi. Serangan Salami digunakan
untuk melakukan kejahatan ekonomi.
• Why?
• Manusia ataupun komputer terkenal
rentan terhadap kesalahan kecil
yang melibatkan pembulatan dan
pemotongan.
• Programmer jahat.
 Suppose an account generates $10.32 in interest
 Would the account-holder notice if there were
only $10.31? Or $10.21? Or $9.31?
 Highly unlikely for a difference of $0.01, and not
very likely for $1.01
PENETRATED AND PATCH

Search for and repair flaws

4 alasan mengapa penetrasi-dan-patch adalah strategi yang –kadang- salah arah:

• Tekanan untuk memperbaiki masalah tertentu mendorong pengembang untuk
mengambil fokus sempit pada kesalahan itu sendiri dan bukan pada kontek
secara luas.
• Perbaikan pada satu titik, sering kali menimbulkan efek samping yang tidak
jelas di tempat lain selain titik tersebut.
• Memperbaiki satu masalah seringkali menyebabkan kegagalan di tempat lain.
• Kadang terjadi juga, kesalahan tidak dapat diperbaiki dengan benar karena
sebagai konsekuensinya fungsionalitas atau kinerja sistem akan terganggu.
IDENTIFYING AND CLASSIFYING FAULTS

• Kesalahan yang tidak disengaja

It doesn’t matter whether
the stone hits the pitcher
or the pitcher hits the
stone, it’s going to be bad
for the pitcher.
dapat menyebabkan kerugian
yang sama besarnya bagi
pengguna dan data mereka.
• Seringkali kesalahan/ kelemahan
yang tidak disengaja, menjadi
sumber serangan dan
membahayakan system.
IDENTIFYING AND CLASSIFYING FAULTS

Sebagai manusia, kita tidak memiliki teknik untuk menghilangkan atau mengatasi
semua kelemahan keamanan program, selalu akan ada celah sesuai kodrat manusia.

• Jadi, kontrol terhadap program sebaiknya diberlakukan pada programmer maupun

aplikasi tersebut, secvara keseluruhan dan terus menerus.
• Perlu dibuat juga semacam daftar tentang”sesuatu yang tidak boleh dilakukan.
Misalnya: menyimpan password sembarangan.
• Meskipun diharapkan bahwa tes dilakukan secara mendalam untuk setiap bagian
program, namun seringkali kita tidak dapat melakukanya secara lengkap.
• Dunia pemrograman dan rekayasa perangkat lunak berkembang sengat pesat, lebih
cepat dibanding teknologi keamanan komputer. Meskipun idealnya adalah seiring.
IDENTIFYING AND CLASSIFYING FAULTS

Pada dasarnya tidak ada jalan singkat untuk mencapai suatu target keamanan computer.
Tidak ada Solusi cepat untuk masalah keamanan computer, semua harus dilakukan secara bertahap
dan terkolaborasi.
Ada 6 kategori kesalahan (cacat) yang tidak disengaja:

1. Validation error(incomplete or inconsistent)  pengecekan tentang

izin masuk system.
2. Domain error  Controlled access to data.
3. Serialization and aliasing  Program flow order
4. Inadequate identification and authentication  Basis for
authorization
5. Boundary condition violation  Failure on first or last case
6. Other exploitable logic errors
IDENTIFYING AND CLASSIFYING FAULTS

Setiap masalah pada software (khususnya yang berhubungan

dengan keamanan), tidak hanya menimbulkan permasalahan pada
software tapi akan berakibat pada bisnis atau kehidupan secara
keseluruhan.

Tidak harus banyak celah dan banyak serangan, namun satu

celah dan satu serangan saja pada software, cukup untuk
membuat permasalahan besar pada bisnis organisasi atau
kehidupan.
SECURE SOFTWARE DESIGN ELEMENT

A modular component usually

Modularization has high cohesion and low
coupling.
Pembagian suatu task menjadi beberapa
subtask.
 Komponen yang terhubung serasi (kohesif)
akan memiliki focus yang sangat tinggi pada
tujuan.
 Akan memperkecil kesalahan dan kemungkinan
Advantages gangguan pada saat implememntasi.
• Maintenance
• Understandability
• Reuse
• Correctness
• Testing
 SECURE SOFTWARE DESIGN ELEMENT
• Encapsulation
• Teknik mengemas informasi (di dalam komponen) sedemikian rupa untuk menyembunyikan apa yang
seharusnya disembunyikan dan memperlihatkan apa yang dimaksudkan untuk terlihat.
• Suatu komponen hanya dipengaruhi dengan cara yang diketahui oleh komponen lain dalam sistem.
• Antarmuka sesedikit mungkin digunakan.
• Information Hiding
• Perancang komponen lain tidak perlu mengetahui bagaimana modul menyelesaikan fungsinya.
• Pengembang jahat tidak dapat dengan mudah mengubah komponen orang lain jika mereka tidak
mengetahui cara kerja komponen tersebut.
• Mutual Suspicion
• Kewaspadaan bahwa komponen lain bisa membahayakan suatu komponen.
• Suatu komponen saling “waspada”terhadap komponen lain, sehingga terjadi filtering pada saat suatu
komponen dipanggil oleh komponen lain.
• Confinement
• Suatu teknik yang digunakan oleh sistem operasi pada program yang dicurigai untuk membantu
memastikan bahwa kemungkinan kerusakan tidak menyebar ke bagian lain dari suatu system.
• Program membatasi agar akses benar-benar diijinkan sesuai keperluanya.
 SECURE SOFTWARE DESIGN ELEMENT

• Genetic Diversity
• Untuk alasan kenyamanan dan biaya, kita sering
merancang sistem dengan perangkat lunak atau Ada 2 cara membangun desain perangkat
perangkat keras (atau keduanya) dari satu vendor. lunak:
• Beresiko jika banyak komponen sistem berasal dari
satu sumber atau bergantung pada satu 1. Salah satu caranya adalah dengan
komponen. membuatnya sesederhana mungkin
• Simplicity
sehingga jelas tidak ada
kekurangannya.
• Lebih mudah dipahami, memberikan lebih sedikit
ruang untuk kesalahan (menhindari terjadinya 2. Cara lainnya adalah dengan
kesalahan) , dan lebih mudah untuk meninjau membuatnya sedemikian rumit
kesalahannya. sehingga tidak ada kekurangan yang
• Seluruh anggota tim desain dan implementasi terlihat jelas.
dapat memahami peran dan ruang lingkup setiap
elemen desain.
• Memfasilitasi pemeliharaan yang benar.
DESIGN PRINCIPLES FOR SECURITY

Least Privilege
Permission Based (Fail-Safe Defaults)
Subjek harus diberikan hanya hak-hak
Subjek tersebut harus ditolak aksesnya ke objek, apabila
istimewa yang diperlukannya untuk
memang subjek memang diberi akses untuk ke obyek
menyelesaikan tugasnya.
tersebut.
Economy of Mechanism
Separation of Privilege
Mekanisme keamanan sebaiknya
Suatu sistem tidak boleh memberikan izin berdasarkan
disediakan sesederhana mungkin,
satu kondisi saja.
namun tetap aman.
Least Common Mechanism
Open Design
Mekanisme yang digunakan untuk mengakses sumber
Keamanan suatu mekanisme tidak boleh
daya tidak boleh digunakan Bersama.
bergantung pada kerahasiaan desain
Ease of use (Psychological Acceptability)
atau implementasinya.
Sebaiknya keamanan yang diterapkan tidak menjadikan
Complete Mediation
system menjadi sulit diakses.
Semua akses ke objek harus diperiksa
untuk memastikan bahwa akses
tersebut diizinkan.
 ​

TOP 10 SECURE CODING PRACTISE

• Validasi masukan.
• Perhatikan peringatan compiler.
• Arsitek dan desain untuk kebijakan keamanan.
• Tetap sederhana.
• Defaultnya adalah menolak.
• Patuhi prinsip hak istimewa paling rendah.
• Sanitasi data yang dikirim ke sistem lain.
• Latih pertahanan secara mendalam.
• Gunakan teknik jaminan kualitas yang efektif.
• Mengadopsi standar pengkodean yang aman.
 SECURE SOFTWARE DEVELOPMENT PROCESS
Pengembangan perangkat lunak
adalah upaya kolaboratif, yang
melibatkan orang-orang dengan
keahlian berbeda yang
menggabungkan keahlian mereka
untuk menghasilkan produk yang
berfungsi dengan baik.
Development requires people who
can do the following
• Specify the system
• Design the system
• Implement the system
• Test the system
• Review the system at various stages
• Document the system
• Manage the system
• Maintain the system
 SECURE SOFTWARE DEVELOPMENT PROCESS

• Several key techniques for building

“solid software”
• Peer reviews
• Hazard analysis
• Good design
• Prediction
• Static analysis
• Configuration management
• Analysis of mistakes
SECURE SOFTWARE DEVELOPMENT PROCESS

Berbagi produk 3 types of peer reviews

dengan rekan kerja Review
yang dapat Walk-through
berkomentar untuk Inspection
Peer Reviews produk berkualitas.

• Pantau dengan cermat apa yang ditemukan oleh reviewer dan seberapa cepat dia
menemukannya.
• Apakah reviewer tertentu memerlukan pelatihan?
• Apakah jenis kesalahan tertentu lebih sulit ditemukan dibandingkan kesalahan lainnya?
• Buatlah daftar periksa item yang akan dicari dalam ulasan mendatang.
• Seorang programmer yang cerdik dapat menyembunyikan beberapa kekurangan ini.
• Peluang penemuan meningkat ketika pemrogram yang kompeten.
• Meninjau desain dan kodenya, terutama ketika komponennya kecil dan dienkapsulasi.
 SECURE SOFTWARE DEVELOPMENT PROCESS

• Hazard analysis should begin when

Serangkaian teknik sistematis • You first start thinking about building
yang dimaksudkan untuk a new system.
mengekspos keadaan sistem • Someone proposes a significant
yang berpotensi upgrade to an existing system
membahayakan system. • Hazard analysis should continue
Hazard Analysist
throughout the system life cycle.
A variety of techniques
• Hazard and Operability Studies (HAZOP)
• Failure Modes and Effects Analysis (FMEA)
• Fault Tree Analysis (FTA)

Known Cause Unknown Cause

Deductive analysis
Known Effect Description of system behavior
FTA
Inductive analysis Exploratory analysis
Unknown Effect
FMEA HAZOP
SECURE SOFTWARE DEVELOPMENT PROCESS

Good Design

• Menggunakan filosofi toleransi kesalahan.

• Mengisolasi kerusakan yang disebabkan oleh kesalahan dan
meminimalkan gangguan pada pengguna.
• Menangkap alasan desain dan sejarah.
• Alasan sistem dibangun dengan satu cara, bukan cara lain.
• Menggunakan pola desain.
• Desain apa yang paling cocok digunakan dalam situasi apa?
SECURE SOFTWARE DEVELOPMENT PROCESS

Good Design
Kebijakan yang konsisten untuk penanganan kesalahan.
Retry
• Restore the system to its
previous state
• Perform the service again,
using a different strategy
Correct
• Restore the system to its
previous state
• Correct some system
characteristic
• Perform the service again,
using the same strategy
Report
 Restore the system to its
previous state
 Report the problem to an
error-handling component
 Do not provide the service
again
SECURE SOFTWARE DEVELOPMENT PROCESS
Memprediksi risiko yang bisa
terjadi dalam membangun
dan menggunakan system.
Prediction
• Risk prediction and management
• Decide which controls to use and
how many
• What if our risk predictions are
incorrect?
• Defense in depth
 SECURE SOFTWARE DEVELOPMENT PROCESS

• Usually performed before

peer review
Examine the characteristics of • Several aspects of the design
design and code
and code
• Control flow structure
Static Analysis
• Data flow structure
• Data structure
 SECURE SOFTWARE DEVELOPMENT PROCESS

Configuration Control
 When we develop software, it is important to know who is making which changes
to what and when
 Reasons to change software
• Corrective changes • Perfective changes
• Correct faults identified • Perfect existing acceptable
• Adaptive changes functions
• Applied to the system after • Preventive changes
its initial fielding, to reflect • Address ways to avoid
changing user needs possible problems in the
future
SECURE SOFTWARE DEVELOPMENT PROCESS

• 4 activities are involved in configuration

management
Configuration Control
• Configuration identification
• Change management
Proses dimana kita • Configuration audit
mengontrol perubahan • Status accounting
selama pengembangan
dan pemeliharaan. • Performed by a configuration and change
control board (CCB)
• Representatives from all organizations with a
vested interest in the system, perhaps
including customers, users, and developers
SECURE SOFTWARE DEVELOPMENT PROCESS

Configuration Control
• Coordinating separate, related versions
• Separate files
• Different files for each release or version
• Delta
• The difference file which contains editing commands to describe the ways
to transform the main version (particular version) into the variation
• Conditional compilation
• A single code component addresses all versions, relying on the compiler to
determine which statements to apply to which versions
SECURE SOFTWARE DEVELOPMENT PROCESS

• Document our decisions

• What we decided to do and why
• What we decided not to do and why
• Information about the failures
• How we found and fixed the
Lesson From underlying faults
Mistake • Build checklists and codify guidelines
SECURE SOFTWARE DEVELOPMENT PROCESS

Security Audits
Check each project’s
Standards of
compliance with standards and
Program Development guidelines
 SECURE SOFTWARE DEVELOPMENT PROCESS
Process Standards
 You have 2 friends
Sonya
Sonya is extremely well organized. She
keeps lists of things to do, she always
knows where to find a tool or who has a
particular book, and everything is
completed before its deadline.
Dorrie
Dorrie is a mess. She can never find her
algebra book, her desk has so many piles of
papers you cannot see the top, and she
seems to deal with everything as a crisis
because she tends to ignore things until the
last minute.

 Whom would you choose to organize and run a major project, a new product launch, or a multiple-
author paper?

Software built in an orderly manner

has a better chance of being good or secure than software
developed in a haphazard way
SECURE SOFTWARE DEVELOPMENT PROCESS

We should be skeptical of new technology’s promise

to make sweeping improvements
TETSING

• Goal: make the product failure free

(eliminating the possibility of failure)
• Realistically, testing will only reduce the
likelihood or limit the impact of failures
• Find as many faults as possible and write up
the findings
• Developers can locate the causes and repair
the problems if possible
TESTING

Developers grow trees • Difficulty

• Side effects, dependencies,
Testers manage forests unpredictable users, and flawed
implementation bases (languages,
compilers, infrastructure)

• We have to look for the hundreds

of ways the program might go
wrong
TESTING

• Types of Testing 2 perspectives

• Unit testing • Black-box testing
• Integration testing • Testers cannot “see inside” the system
• Function test • They apply particular inputs and verify
that they get the expected output
• Performance test
• Acceptance test • Clear-box testing (white-box testing)
• Installation test • Testers can examine the design and
• Regression testing code directly
• Generate test cases based on the
code’s actual construction
TESTING

 Key Ingredients
 Product expertise
 Coverage
 Risk analysis
 Domain expertise
 Common vocabulary
 Variation
 Boundaries
EFECTIVENESS OF TESTING

• Use different techniques to uncover different kinds of

faults during development
• It is not enough to rely on a single method for
catching all problems

• Who does the testing?

• From a security standpoint, independent testing is
highly desirable
• It may prevent a developer from attempting to hide
something in a routine or keep a subsystem from
controlling the tests that will be applied to it
LIMITATION OF TESTING

• Passing tests does not demonstrate the absence of problems.

• Complete testing is complex and time consuming.
• Testing only observable effects does not ensure any degree of completeness.

• Testing the internal structure of a product involves modifying the product by

adding code to extract and display internal states
• Affects the product’s behavior
• Can be a source of vulnerabilities
• Can mask other vulnerabilities
• In testing real-time or complex systems, it is hard to reproduce and analyze
problems reported
• Testing is almost always constrained by a project’s budget and schedule
TESTING ESPECIALLY FOR SECURITY

Ethical Hacking
Trying to crack
Penetration Testing
the system being tested

 Tiger team analysis

 As opposed to trying to break into the system for unethical reasons
 Resembles what an actual attacker might do
TESTING ESPECIALLY FOR SECURITY

Verification
Verification checks the quality of the
Demonstrate formally the
implementation.
“correctness” of certain
specific programs

Validation
Assuring that the system Validation makes sure that the developer is
developers building the right product according to the
have implemented all specification.
requirements
CYBER SECURITY

As the world is increasingly

interconnected,
everyone shares the responsibility of
securing cyberspace.
TERIMA KASIH
Slamet Aji Pamungkas
Tangerang, Februai 2023