Kriteria Evaluasi Keamanan Perangkat - Common criteria for dummies, Sistem Pembayaran LessCash

COMMON CRITERIA FOR DUMMIES

by Agus Reza Aristiadi Nurwa

23213307

May 20141

5 FAKTA TENTANG IT SECURITY EVALUATION

1

2

3

4

Mungkinkah untuk memastikan tingkat keamanan dari suatu produk?TIDAK, kita hanya bisa mendemonstrasikan ‘insecurity’ dari sebuah produk.Tapi….Kita bisa “offer confidence degrees” di dalam security sebuah produk.Bagaimana memperoleh tingkat “confidence degrees” ini?If a method that generates secure products is followed and vulnerabilities have not been found, we will affirm that it is secure.Atas dasar keyakinan apa kita bisa memperolehnya ?Berdasarkan ‘effort’ yang kita lakukan untuk mencari ‘vulnerabilities’ pada produk tersebut.2

NUNGGUIN YANG KE- YA? :P

5

source: common criteria tutorial T01.pdf3

COMMON CRITERIA IS…

IT Product

Standardize Security Evaluation for

Security requi

Methodology Testing EvaluationFunctional requi

Documents ber-standar yang sistematis

Output

4

Untuk selanjutnya,

Common Criteria akan di sebut sebagai CC

Protection Profiles akan disebut sebagai PP

Security Target akan disebut sebagai ST

Produk yang sedang dievaluasi (Target of Evaluation disebut sebagai TOE

1

2

3

4

5

BUAT APA ??Menentukan fitur keamanan dari suatu produk

Membantu dalam pembangunan fitur keamanan pada suatu produk

Evaluasi fitur keamanan dari suatu produk

Mendukung proses pengadaan barang dengan fitur keamanan

1

2

3

4

6

SECURITY ADALAH SESUATU YANG SULIT DI UKUR OLEH KONSUMEN

Security seperti apa yang konsumen perlukan ?

Tingkat Security sebuah produk belum tentu memenuhi apa yang konsumen perlukan.

The securities declared on the product are TRUE.

1

2

3

**. evaluasi suatu produk menggunakan metode Common Criteria (CC) menjadi sangat penting untuk menentukan level TRUEness ini. Ini dapat di jamin dengan adanya PP dan ST

7

2 TIPE PEMBELIAN1

2

specification-based purchasing process

selection-based purchasing process

“customer langsung mengontak developer, dan memesan untuk dibuatkan produk sesuai dengan spesifikasi keamanan dan fungsionalitas yang customer pesan”

“customer langsung membeli barang yang telah dijual bebas sesuai dengan fungsi keamanan yang ingin di peroleh”

8

CONTOH KASUS !

SELECTION-BASE !

PURCHASING PROSES

2

9

Suatu hari di suatu ruangan server back-up nilai-nilai mahasiswa ITB….

server ini berfungsi untuk membackup database nilai-nilai mahasiswa ITB, tetapi masih dalam satu jaringan dengan server database utama.

server backup ini bertugas untuk mencatat semua LOG dan semua perubahan informasi serta history perubahan nilai.

10

Suatu ketika server database utama ini diserang oleh serangkaian serangan besar, sehingga penyerang dapat mengubah nilai-nilai beberapa mahasiswa itb.

penyerang juga tidak lupa untuk menyerang server backup dan menghapus jejak dengan menghapus history dan LOG pada server backup.

11

ketika keesokan harinya, admin di adukan oleh beberapa mahasiswa yang nilainya berubah menjadi E (maaf ya, contohnya jadi E, bukan jadi A :P)

ketika admin melakukan penyelidikan dengan segala macam forensic tools, admin tidak dapat mencari adanya indikasi perubahan nilai tersebut pada server, karena pada server database utama maupun database backup tidak ditemukan history yang menjustifikasi perubahan tersebut

12

Asumsi cerita diatas, router serta firewall yang digunakan adalah sekelas Cisco dan Juniper dengan spesifikasi security EAL4

Agar kejadian serupa tidak terulang lagi

Apa yang harus dilakukan oleh Admin?

13

Dari masalah tersebut, kemudian admin mengubah infrastrukturnya.

dengan cara, memisahkan jaringan database backup dengan jaringan database utama, dengan sebuah firewall yang sangat kuat.

emang ada firewall yang sangat kuat ??, dari cerita diatas, router dan firewall dg spek common criteria level EAL4+ saja masih bisa kebobolan!

14

Tapi kira-kira, apa yang bisa menyebabkan, router sekelas Cisco dan Juniper dengan sertifikasi EAL4+ bisa di retas?? :D

15

Jawabannya ADA.

karena server backup hanya digunakan untuk menyimpan data dari database utama. maka traffic yang diizinkan dan diperlukan hanya dari luar menuju ke database backup.

dan database backup hanya bisa di akses dari dalam, dan tidak bisa di remote.

Rules:

16

17

18

19

Dengan menggunakan Fox Data Diode, maka sekarang sang mimin a.k.a sang admin telah sangat merasa aman, karena produk tersebut juga telah diuji dan disertifikasi serta mendapatkan EAL7+

**) EAL = Evaluation Assurance Level

EAL menentukan tingkat perasaan seberapa aman suatu produk.

20

dari fungsionalitas tersebut, kemudian admin mencari firewall yang cocok dengan fungsi dan keamanan yang sesuai dengan keperluan yang disebutkan di atas.

ternyata di pasaran, ada firewall yang mempunyai fungsionalitas dan keamanan yang diperlukan admin, apakah dia?

21

CONTOH KASUS !

SPESIFICATION-BASE !

PURCHASING PROSES

1

22

SUATU HARI….

Presiden SBY memerintahkan jajarannya, untuk menyediakan Hangpong (eh handphone ding :P),

Sang presiden menginginkan sebuah handphone layar datar (bukan cembung apalagi cekung) yang dapat berkomunikasi (sms, telpon, email, bbman, whatsappan) dengan para menteri dengan aman, tanpa bisa disadap oleh NSA, MNC, TPI, RCTI apalagi ANTV.

23

TERUS GIMANA??…Perintah tersebut kemudian di delegasikan para jajaran staf-staf ahli kepresidenan, melalui proses tender yang rumit, dari upacara simbolis peletakan batu pertama, kedua, ketiga sampai jadi sebuah tembok, maka akhirnya ditunjuklah seorang professor ternama dalam bidang keamanan informasi di ITB, yakni Prof. Dr. Sarwono Sutikno, CISA, CISM, CISP. sebagai ketua timnya.

**)cerita ini hanya fiktif belaka, pak Sarwono belum menjadi prof.24

LANJUTANNYA…Sebelum memberikan spesifikasi handphone yang akan dibuat ke Samsung, HUAWEI, ZTE, PT.Inti, dan vendor2 terkemuka dunia lainnya.

Pak prof. membuat sebuah spesifikasi yang ditentukan berdasarkan requirement Bapak Presiden.

Agar para vendor mengerti apa yang Bapak Presiden mau, Pak prof. menuangkan spesifikasi requirement funtional dan security tsb ke dalam sebuah dokumen standart dunia yaitu Protection Profile Document.

**)cerita ini hanya fiktif belaka, pak Sarwono belum menjadi prof.25

Common Criteria

Protection Profiles (PP)

Security Target (ST)

Documents

Documents

Dibagi menjadi 2 buah dokumen formal

Implementasi

26



Documents

Documents

Dibuat Oleh User/ Calon Pengguna/

Calon Pembeli/ Pembuat Kebijakan/

Product

Dibuat Oleh Developer/

Kumpulan Developer Product

27



Definitions

Definitions

an implementation- independent statement of security needs for a TOE type.

an implementation-dependent statement of security needs for an identified TOE

28

ENTITAS DALAM COMMON CRITERIA

CUSTOMER

EVALUATOR

DEVELOPER

1

2

3

PRODUK429

Saya sendiri,

Sekumpulan developer smart card (Atmel + NXP + JAVA + HITACHI)

Orang satu kantor dinas sosial

ParPol

CUSTOMER1


**) Customer disini, adalah customer yang boleh membuat PP30


EVALUATOR2

31


DEVELOPER3

32


PRODUK4

33

34

BAGAIMANA PP DIBUAT?“formalizing customer requirements into PP”

PP

Requirements

Customers

defines

formalizes into1

2

35

PP

Requirements

Customers

defines

formalizes into1

2

We need something product, that is

secure, functional, etc

36

BAGAIMANA ST DIBUAT?“Building ST from PP”

PPRequirements

Customers

defines

formalizes intoST

Complies with

Developer

defines

for reference to

1

2

3

4

5

37

formalizes into

BAGAIMANA ST DI EVALUASI?“evaluate TOE by evaluator”

Requirements

Customers

defines

Complies with

Developer

defines ST &

Create TOE

for reference to

1

2

3

4

5

STcertified

PublishEvaluator

evaluate by

6

7PP

TOE

+ ST

**) TOE = Target of Evaluation = product 38

–Common Criteria Tutorial

The end result of an evaluation is never “this IT product is secure”,

but is always “this IT product meets, or not, this

security specification”

39

PROTECTION PROFILE (PP) DOCUMENTS

1

2

3

4

5

640

BAGAIMANA CARA MEMBUAT PP ?

Read :[CC1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Version 3.1, Revision 4, September 2012 (Free)

[CC2] Common Criteria for Information Technology Security Evaluation, Part 2: Security functional requirements, Version 3.1, Revision 4, September 2012 (Free)

[CC3] Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance requirements, Version 3.1, Revision 4, September 2012 (Free)

Seriously, this is important and the easy part !

ISO15446 : Information technology — Security techniques — Guide for the production of Protection Profiles and Security Targets. (Free)

41

Jadi Yang Saya Kerjakan Di Dalam Mata Kuliah Secure

Device Ini…

42

Common Criteria



Documents

Documents

Dibagi menjadi 2 buah dokumen formal

Saya membuat ini !

43

TERIMA KASIH

~ Salam Lemper

44

PROTECTION PROFILE UNTUK SECURE RFID READER DI KASIR

YANG DIGUNAKAN DALAM SISTEM PRIVATE E-PAYMENT

!oleh

!Agus Reza Aristiadi Nurwa

23213307

45

Secure RFID Reader di Kasir Protection Profiles!(draft) Version 1.0 - 5 Mei 2014!

!!!!!

Common Criteria for IT Security Evaluation Protection Profiles !!!!Protection Profile

Untuk Secure RFID Reader di Kasir Yang Digunakan Dalam Sistem Private e-Payment!

!!!

� of �1 14

46


1

2

3

4

5

647


48

PP Introduction Berisikan :

Usage and major security features of the TOE

The TOE type

Required non-TOE hardware/software/firmware

1

2

3

49

50

51

System Private E-Payment

52

Private E-Payment Business Process

53


54

2. Conformance Claims !2.1 Conformance statement PP ini mensyaratkan kesesuainan dari setiap PP/ST ke PP ini. !2.2 CC Conformance Claims PP ini dikembangkan menggunakan Common Criteria Versi 3.1 Revisi 4. !2.3 PP Claim PP ini tidak mengklaim kesesuaian dengan PP yang lain. !2.4 Conformance claim rationale Karena PP ini tidak mengklaim kesesuaian dengan setiap Protection Profile, bagian ini tidak berlaku.

55


56

SECURITY AND EVALUATION CONCEPT

Evaluation

Owners

Confidence

Countermeasures Sufficient

Correct Risk

Assets

requires

provides

that

are

are

and therefore minimize

toand therefore minimize

57

DETERMINE SECURITY PROBLEM DEFINITION (SPD)

Assumption about environtment

Threats to assets

Organizational Securities Policies

Security Problems

1

2

3

58

Peran Entitas Deskripsi

Accounting Manager Pihak yang memiliki otoritas untuk menerima uang dari Teller dan menyetorkannya ke Bank, AM juga bertugas untuk mengawasi uang yang masuk maupun yang keluar dari sistem.

Administrator Pihak yang memiliki otoritas untuk mengkonfigurasi server.

Cashier Pihak yang bertugas untuk memasukkan nominal transaksi ke dalam TOE.

Teller Pihak yang memiliki otoritas untuk menerima uang dari User dan memasukkan nilai nominalnya ke dalam sistem Private E-Payment.

Teknisi Pihak yang memiliki otoritas untuk mengkonfigurasi TOE di pelanggan.

User Individu pengguna sistem Private E-Payment ini.

1

2

3

4

56

3.1 External Entities

59

What is Assets?

“Information and resources to be protected by the countermeasures of a TOE”, ~ISO15408

“Assets typically take the form of information which is stored, processed and transmitted by IT-systems”, ~IT Security Approach

60

Aset DeskripsiKebutuhan Proteksi

Integritas Kerahasiaan Keaslian

Memori Internal EEPROM

Memori yang dipergunakan untuk menyimpan KEY x x x

Konfigurasi Koneksi ke Server

Memuat konfigurasi Alamat IP server, konfigurasi ini menentukan server yang akan dituju oleh TOE ini.

x x x

Firmware Firmware pada Secure RFID Reader ini digunakan untuk mengoperasikan fungsi-fungsi sebagai berikut: memasukkan nilai nominal transaksi ke dalam sistem, membaca kartu RFID user, membuat koneksi ke server dan melakukan permintaan transaksi ke server.

x x x

Segel Segel berfungsi untuk menyegel Secure RFID Reader ini. Jika segel dibuka maka akan jelas terlihat oleh User maupun Teknisi, sehingga dapat dilakukan tindakan pencegahan untuk tidak melakukan transaksi dengan TOE.

x x

3.2 Assets

1

2

3

4

61

Rules to make Assumptions !

Aspects relating to the intended usage of the TOE

Environmental protection of any part of the TOE

Connectivity aspects

Personal aspects

Assumption must be rationale

1

2

3

4

562

Asumsi Deskripsi

A.Trusted_Admins Diasumsikan bahwa administrator dan petugas/teknisi yang mengkonfigurasi dapat dipercaya.

A.Connection Diasumsikan bahwa TOE selalu terhubung dengan Private Local Area Network.

A.Physical_Protection Diasumsikan bahwa Secure RFID Reader telah diinstalasi dengan benar dan di lingkungan konsumen yang aman.

3.3 Assumptions

1

2

3

63

Bagaimana caranya meng-identifikasi ancaman (threat) ?

Sebuah threat selalu berusaha untuk menggagalkan TOE agar TOE bekerja dengan benar. (cari sesuatu yang membuat TOE tidak bekerja dengan semestinya)

Lihat nilai asset yang berada di dalam sebuah TOE dan pengaruhnya jika asset tersebut hilang.

The threats that are of principal interest are those that will be countered by the TOE.

1

2

3

64

Threats DeskripsiT.Eavesdropping_Card Attacker bisa saja menaruh alat sadap pada

komunikasi antara RFID Reader dengan kartu RFID user.

T.Eavesdropping_Comm Attacker bisa saja menyadap komunikasi yang dilakukan antara TOE dengan server.

T.Physical_Tampering Attacker bisa saja membuka TOE ini dan melakukan physical probing untuk mendapatkan data ID Number milik User.

T.Reply_Attack Attacker bisa saja mengirimkan ulang paket yang disadap.

T.Cloning_Key Attacker bisa saja berusaha untuk mendapatkan KEY yang digunakan untuk berkomunikasi ke server.

T.Firmware_Modify Attacker bisa saja mengubah firmware yang ada di dalam TOE

T.Segel Attacker bisa saja merusak segel untuk mengetahui isi dalam TOE.

3.4 Threats

1

2

3

4

5

67

65

Cara menentukan Organizational Securities Policies (OSP)

An OSP is defined as one or more rules, procedures and practices imposed by an organisation in the operational environment.

Buat aturan/prosedur/praktikal yang bisa membantu untuk membatasi security problem.

66

Policies Deskripsi

P.Segel Kondisi segel harus dalam keadaan baik sebelum digunakan.

P.Account Setiap user hanya boleh membuat satu buah account.

3.5 Organizational Policies

1

2

67


68

Security Objectives

Keamanan yang ingin dicapai / ingin diperoleh.

**)fungsinya untuk: 1. counter threats that are not countered by the TOE 2. help satisfy OSPs that are not fully satisfied by the TOE 3. ensure that the environmental assumptions are satisfied

69

70

Security Objectives

Untuk Readernya

Untuk Lingkungan pengoperasian Reader

1

2

Objective Deskripsi

O.Key_Protection TOE harus bisa menjaga kunci yang terdapat di dalam Secure RFID Reader yang digunakan dalam fungsi komunikasi dengan server.

O.Config_Protection TOE harus bisa menjaga data konfigurasi yang disimpan di dalam TOE.

O.Data_Transaksi TOE harus bisa menjaga data temporari selama proses transaksi berlangsung.

O.Physical_Protection TOE harus bisa melindungi hardwarenya sendiri secara fisik dari proses tampering oleh attacker.

O.Unique_Data Data yang dirikimkan oleh TOE harus selalu unik.

4.1 Securities Objectives for the TOE

71

Objective DeskripsiOE.Private TOE harus digunakan di dalam lingkungan

organisasi private. Misalnya digunakan di dalam sebuah kantor tertentu atau sebuah sekolah tertentu.

OE.Trusted_Admins Administrator dan teknisi di dalam organisasi ini dapat dipercaya.

OE.After_Used Setelah digunakan, TOE harus di bawa ke tempat yang aman untuk penyimpanan, selama TOE tidak digunakan.

4.2 Securities Objectives for the operational environment

72

O.Key_P

rotec,on

.

O.Con

fig_P

rotec.on

/

O.Data_Transaksi-

O.Physic

al+Protec0on

+

O.Uniqu

e_Da

ta-

OE.Private+

OE.Trusted_

Admins0

OE.A%

er_U

sed,

Objectives

Threats and Policies

T.Eavesdropping_Card x x xT.Eavesdropping_Comm x x xT.Physical_Tampering x x xT.Reply_Attack x xT.Cloning_Key x x x x xT.Firmware_Modify x xT.Segel x x

P.Segel x xP.Account

4.2 Securities Objectives Rationale

73


74


75

SECURITY REQUIREMENTS KEY CONCEPT

1

2

Functionality

Assurance

“Defines the TOE security characteristics (SFRs)”

“Confidence degree in the enforcement of the security objectives of a TOE”

SARs Correctness & Effectiveness76

–Common Criteria Tutorial

“Greater assurance results from the application of greater evaluation effort:

Scope, Depth and Rigour”

**)oxford dict Rigour — the quality of being extremely thorough and careful: “his analysis is lacking in rigour.”77

JADI, SECURITY FUNCTIONAL REQUIREMENTS (SFR) DALAM CC ADALAH…

TOE Security Objectives

Security Functional

Requirements

ISO/IEC 15408-2

Security Assurance

Requirements

ISO/IEC 15408-3

complies with

78

5.1 Securities Functional Requirements5.1.2 Class FCS: Cryptography Support

5.1.2.1 Cryptography Operation (FCS_COP.1)Crytographic operation - encryption/decription AES (FCS_COP.1/AES)FCS_COP.1/AES The TSF shall perform secure messaging – encrip.on and decrip.on

in accordance with a specified cryptographic algorithm AES and cryptographic key sizes 256 bit that meet the following: [assignment: list of standards].

5.1.3 Class FDP: User Data Protection

5.1.3.1 Data Authentication (FCS_DAU)

Basic Data Authentication (FDP_DAU.1)

FDP_DAU.1.1 The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity of [assignment: list of objects or information types].

FDP_DAU.1.2 The TSF shall provide [assignment: list of subjects] with the ability to verify evidence of the validity of the indicated information.

79

5.1.4 Class FIA: Identification and authentication

5.1.4.1 Authentication failures (FIA_AFL)Authentication failure handling (FIA_AFL.1)FIA_AFL.1.1 The TSF shall detect when [assignment: number]

unsuccessful authentication attempts occur related to [assignment: list of authentication events].!!number = 1 attempt!!list of authentication events = user id failure

FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall [assignment:list of actions].!list of actions = send an error message and stop

5.1.4.2 User authentication (FIA_UAU)User authentication before any action (FIA_UAU.2)FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated

before allowing any other TSF-mediated actions on behalf of that user.

80

5.1.6 Class FPT : Protection of the TOE Security Functions 5.1.6.1 Fail secure (FPT_FLS)

Failure with preservation of secure state (FPT_FLS.1)

FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures occur: [assignment: list of types of failures in the TSF].

5.1.6.2 Internal TOE TSF data transfer (FPT_ITT)

Basic internal TSF data transfer protection (FPT_ITT.1)

FPT_ITT.1.1 The TSF shall protect TSF data from [selection: disclosure, modification] when it is transmitted between separate parts of the TOE.

5.1.6.3 TSF Physical protection (FPT_PHP)

Resistance to physical attack (FPT_PHP.3)

FPT_PHP.3.1 The TSF shall resist [assignment: physical tampering scenarios] to the [assignment: list of TSF devices/elements] by responding automatically such that the TSP is not violated.

5.1.6.7 TSF self test (FPT_TST)

TSF testing (FPT_TST.1)

FPT_TST.1.1 The TSF shall run a suite of self tests [selection: during initial start-up, periodically during normal operation, at the request of the authorised user, at the conditions [assignment: conditions under which self test should occur]] to demonstrate the correct operation of the TSF.

FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the integrity of TSF data.

FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable code.!Refinement : users = device maintainer, security administrator.

81

GUIDE UNTUK MENENTUKAN ASSURANCE LEVEL

The value of the assets to be protected and the perceived risk of compromise of those assets.

Technical feasibility.

Likely development and evaluation costs.

Required timescales for development and evaluation of the TOE.

Perceived market requirement (in the case of products).

Any identified dependencies of functional components on assurance components.

1

2

3

4

5

6

82

ASSURANCE LEVEL

83

EAL7

EAL6

EAL5

EAL4

EAL3

EAL2

EAL1

“Greater assurance results from the application of greater

evaluation effort: Scope, Depth and Rigour”

Security Assurance

Requirements

ISO/IEC 15408-3

84

5.2 Securities Assurance RequirementsAssurance Class Assurance componentsADV: Development ADV_ARC.1 Security architecture description!

ADV_FSP.4 Complete functional specification!ADV_IMP.1 Implementation representation of the TSF!ADV_TDS.3 Basic modular design

AGD: Guidance documents AGD_OPE.1 Operational user guidance!AGD_PRE.1 Preparative procedures

ALC: Life-cycle support ALC_CMC.4 Production support, acceptance procedures and automation!ALC_CMS.4 Problem tracking CM coverage!ALC_DEL.1 Delivery procedures!ALC_DVS.1 Identification of security measures!ALC_LCD.1 Developer defined life-cycle model!ALC_TAT.1 Well-defined development tools

ASE: Security Target evaluation ASE_CCL.1 Conformance claims!ASE_ECD.1 Extended components definition!ASE_INT.1 ST introduction!ASE_OBJ.2 Security objectives!ASE_REQ.2 Derived security requirements!ASE_SPD.1 Security problem definition!ASE_TSS.1 TOE summary specification

ATE: Tests ATE_COV.2 Analysis of coverage!ATE_DPT.1 Testing: basic design!ATE_FUN.1 Functional testing!ATE_IND.2 Independent testing - sample

AVA: Vulnerability assessment AVA_VAN.3 Focused vulnerability analysis

EAL4

85

The security objectives rationale also demonstrates that the tracing is effective:

All the given threats, OSPs and assumption are addressed (i.e. countered, enforced and upheld respectively).

Threats Organizational Securities Policies Assumptions

Security Objectives for the TOEs

Security Objectives for the Operational

Environtment

86

5.3 Securities Requirement Rationale

O.Key_P

rotec,on

.

O.Con

fig_P

rotec.on

/

O.Data_Transaksi-

O.Physic

al+Protec0on

+

O.Uniqu

e_Da

ta-

OE.Private+

OE.Trusted_

Admins0

OE.A%

er_U

sed,

Objectives

Security Functional Requirments (SFRs)

FCS_COP.1/AES x x x xFDP_DAU.1.1 xFDP_DAU.1.2 xFIA_AFL.1.1 xFIA_AFL.1.2 xFIA_UAU.2.1 xFPT_FLS.1.1 xFPT_ITT.1.1 xFPT_PHP.3.1 x xFPT_TST.1.1 x x xFPT_TST.1.2 x x xFPT_TST.1.3 x x x

87

–Agus Reza Aristiadi Nurwa

“Kesempurnaan hanya milik Allah SWT, Mohon maaf masih banyak kekurangan”

88