Your SlideShare is downloading. ×
0
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Rebecca Bond's - A Locksmith's Approach to Separation of ...
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rebecca Bond's - A Locksmith's Approach to Separation of ...

590

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
590
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • In DB2 9.7, there are numerous opportunities for achieving a more robust security architecture. One of those is the ability to truly employ the concept of “Separation of Duties” also known as SoD. In thinking about security and some of the governmental and industry security regulations that are in place, one mandate is to lessen security risk by lessening the power held by one individual or group. Even without a mandate, common sense and “security in depth” principles serve to remind us that a multi-layered defense, incorporating least privilege and separation of duties, is a wise approach toward data protection. Given recent headlines regarding security breaches, data certainly seems to  need  to be protected; in fact, it almost seems to be begging us to do a better job of protecting it. DBAs and technologists who live close to all this valuable data serve at the forefront of this battle to protect and secure these enterprise assets. Making SoD a reality is one step that they can incorporate into their defense-in-depth armor.
  • From the DB2 9.7 Information Center: The ACCESSCTRL authority level provides administrative authority to issue the following GRANT (and REVOKE) statements. ACCESSCTRL authority can only be granted by a user with SECADM authority. The ACCESSCTRL authority cannot be granted to PUBLIC.GRANT (Database Authorities)ACCESSCTRL authority does not give the holder the ability to grant ACCESSCTRL, DATAACCESS, DBADM, or SECADM authority. Only a user who has SECADM authority can grant these authorities. GRANT (Global Variable Privileges) GRANT (Index Privileges) GRANT (Module Privileges) GRANT (Package Privileges) GRANT (Routine Privileges) GRANT (Schema Privileges) GRANT (Sequence Privileges) GRANT (Server Privileges) GRANT (Table, View, or Nickname Privileges) GRANT (Table Space Privileges) GRANT (Workload Privileges) GRANT (XSR Object Privileges) ========================== The DATAACCESS authority level provides the following privileges and authorities. It can be granted only by a user who holds SECADM authority. The DATAACCESS authority cannot be granted to PUBLIC.LOAD authority SELECT, INSERT, UPDATE, DELETE privilege on tables, views, nicknames, and materialized query tables EXECUTE privilege on packages EXECUTE privilege on modules EXECUTE privilege on routinesExcept on the audit routines: AUDIT_ARCHIVE, AUDIT_LIST_LOGS, AUDIT_DELIM_EXTRACT. Database authorities (non-administrative)To perform activities such as creating a table or a routine, or for loading data into a table, specific database authorities are required. For example, the LOAD database authority is required for use of the  load  utility to load data into tables (a user must also have INSERT privilege on the table).
  • Once the migration is complete, the SECADM may want to revoke these “migrated authorities” and re-grant them based on the new SoD security model. Of course, since this is a pre-existing database, authority changes should only be undertaken following some solid analysis and testing to make sure that nothing is going to break once the changes are made, unless you just happen to like chaos. Obviously, the true separation of the SECADM and DBADM roles is a major boost to the principles of SoD and least privilege. However, to me, one of the best SoD features is that DBAs no longer have to gain access to the data as a “ride along” with the ability to do their administration tasks. The SYSADM authority now matches the role it should play, as the “manager of the instance.” The high level DBADM authority has been scaled back to allow functionality without privilege escalation. DBAs typically don’t need to see the data and now, they don’t have to automatically acquire the ability to do so. In this case, a little less power means an enhanced security architecture. So, what does all this mean for DBAs when thinking about SoD? The answer is, “it depends”. I’ve worked in enough shops to know that there is no standard template for aligning DBAs to tasks, so what might work regarding SoD in one enterprise could be a complete disaster in another. However, thinking about this logically, DB2 9.7 has provided exactly what we wanted -- multiple security layers, multiple locksmith opportunities and a greatly enhanced layered security configuration ability. Now we have to do our part to make Separation of Duties work for our enterprise.
  • I am a DBA, so why am I telling you to lock down your DBADM authority? In the past, I’ve been put in a position of having to “over grant” authorities because there was simply no feasible way for folks to get their work done otherwise. Sometimes, high level authorities had to be granted to IDs supplied by COTS (commercial, off the shelf) vendors just to make their applications function. But, with the new granularity of the SoD options in DB2 9.7, the need to “over grant” is gone. If you’ve ever been in a situation where data was changed and the DBAs got the blame, then you may be rejoicing that DBAs no longer “have” to have access to the data. Without access to the data, the DBAs can eliminate themselves from suspicion, whether anyone else believes them or not. With ACCESSCTRL (grants/revokes) and DATAACCESS offering the ability to be separately granted without the higher level DBADM authorities coming along for the ride, now those COTS products that have to have one or the other or both, can get those authorities without additional escalation of authorities.
  • Hard to fight a battle if you don’t know who’s for you or who’s against you ! SYNTAX: >>-AUTH_LIST_AUTHORITIES_FOR_AUTHID--(--authid--,--authidtype--)->< authidtype can be U (user), G (group) or R (role)
  • There should be written policies on How to Grant DBADM and ALL high level authorities.
  • Be careful when revoking authorities. Make sure that you achieve what you intended. When revoking DBADM, make sure you check to see if ACCESSCTRL and DATAACCESS have been inadvertently left behind. Double check your work.
  • SQLADM A lot of authority surrounding Monitoring and Tuning activities: Create/Drop Event Monitors/Set Event Monitor State PREPARE & EXPLAIN (more on EXPLAIN in the next slide) FLUSH: EVENT MONITOR, OPTIMIZATION PROFILE CACHE, PACKAGE CACHE SELECT on the system catalog tables and views EXECUTE system-defined routines (except audit routines) RUNSTATS/REORGs And even more.
  • WLMADM is another subset of the DBADM authority. The ability to segregate authorities with DB2 9.7 helps security gurus practice the security principle of “least privilege” and Separation of Duties. WLMADM authority gives a user the ability to perform the following operations:Create, alter, comment on, and drop the following workload manager objects: Histogram templates Service classes Thresholds Work action sets Work class sets Workloads Grant and revoke workload privileges Execute the system-defined workload management routines.
  • I really like this new EXPLAIN authority. I like the ability to allow Developers to be pro-active about performance without risking unwanted data exposure. EXPLAIN authority is a subset of the DBADM authority, but it has no inherent privilege to access data stored in tables. Explain can be granted by a user who has ACCESSCTRL or SECADM authority. This is a Good tip for ALL privileges and Authorities: Remember that once the work is done and EXPLAIN is no longer needed, it should be revoked. It CAN be granted to a role (which is a great option) or to a user or group. While it can be granted to PUBLIC, I would not suggest you do that. A syntax example using roles: (my id holds SECADM) $> db2 "create role power_developers" $> db2 "grant explain on database to power_developers" $> db2 "grant role power_developers to user locksmith" $> db2 "grant role power_developers to user dev_guru"
  • I firmly believe that as security professionals, we have an obligation to share information. I welcome any learning opportunity that fosters a more robust security architecture. Please feel free to send me emails with comments, thoughts, disagreements, articles or lessons learned. The more we know…the better prepared we can be, as a security community, to protect and defend.
  • Transcript

    • 1. Presented by: Rebecca Bond a.k.a. DB2Locksmith [email_address] Phone: 434-322-0070
    • 2. What is SoD? <ul><li>According to the SANS Institute of Technology : </li></ul><ul><li>“ Separation of duties is a classic security principle to manage conflict of interest, the appearance of conflict of interest, and fraud. It restricts the amount of power held by any one individual. It puts a barrier in place to prevent fraud that may be perpetrated by one individual. Fraud will still occur if there is collusion. To properly identify separation of duties issues, you will first need to create an information flow diagram for every function within each area of the organization. ” </li></ul>
    • 3. Why Are DBAs Involved Now ? <ul><li>DBAs should have always been involved in enforcing appropriate SoD, but the ability to do so had been limited, not just in DB2, but in most database products. </li></ul><ul><li>With breaches increasing, fraud on the rise and concerns about data loss, implementing SoD for databases is a logical step toward enhancing security. </li></ul>
    • 4. Separation of Duties (SoD) <ul><li>Supports the security concept of Least Privilege </li></ul><ul><li>Separation of Duties serves to lessen risk by dividing the work and re-assigning some of the “power” </li></ul><ul><li>For example, do your DBAs really need to query user data to do their job? If not, why continue to allow them to have access? </li></ul><ul><li>What about security tasks? Should these all reside within the control of one individual or group? </li></ul><ul><li>With DB2 9.7, SoD can be used to reduce these risks and make sense of the term “Least Privilege” </li></ul>
    • 5. History <ul><li>BEFORE: </li></ul><ul><li>SYSADM authority included the ability to configure, start, stop, prune or extract any audit data as well as the ability to access and manipulate data for any database in that instance. </li></ul><ul><li>DBADM authority, the highest database authority, conferred the ability to access data. </li></ul><ul><li>Even though it might not have been wise or necessary, many shops allowed DBAs to hold SYSADM (which also implicitly conferred DBADM) just to make sure anyone on the DBA team could do anything they might possibly need to do in the day-to-day performance of their tasks. </li></ul>
    • 6. In Rides the SECADM <ul><li>Beginning in DB2 9.1, a new security functional job designation was introduced, that of the Security Administrator (SECADM) for the database. </li></ul><ul><li>With DB2 9.7, the SECADM tasks are intensified and Separation of Duties abilities are specifically introduced. </li></ul>
    • 7. Current Day <ul><li>The SYSADMs no longer implicitly get DBADM authority, which means they don’t automatically get data access. </li></ul><ul><li>DBADM, has changed significantly in a manner that tracks well to SoD security concepts and practices. </li></ul><ul><li>New options in the “grant DBADM…” statement can be specified to prevent those who hold DBADM authority from also having the ability to access database user data in user defined tables (DATAACCESS) or perform grants and revokes (ACCESSCTRL). </li></ul><ul><li>The specific SoD benefit, depending on how the DBADM authority is granted in a DB2 9.7 database, is that holders of that authority do not necessarily acquire the ability to access user data or to perform grants/revokes. </li></ul>
    • 8. <ul><li>With DB2 9.7, the SECADM </li></ul><ul><li>functional role has been </li></ul><ul><li>separated from the DBADM </li></ul><ul><li>functional role and the two no </li></ul><ul><li>longer need to overlap in </li></ul><ul><li>order to complete security tasks. </li></ul><ul><li>There are also some new and re-defined authorities. Some were carved out from DBADM authority. Whether new or re-vamped, all of them lend themselves to the Separation of Duties approach to task delegation including: </li></ul>
    • 9. <ul><li>DATAACCESS conveys: </li></ul><ul><ul><li>LOAD authority </li></ul></ul><ul><ul><li>SELECT, INSERT, UPDATE, DELETE privileges on tables, views, MQTs and nicknames </li></ul></ul><ul><ul><li>EXECUTE on packages and routines (except audit routines) </li></ul></ul><ul><li>ACCESSCTRL authority </li></ul><ul><ul><li>Gives the ability to grant/revoke database privileges </li></ul></ul><ul><li>EXPLAIN authority </li></ul><ul><ul><li>Allows the holder to EXPLAIN, PREPARE and DESCRIBE SQL statements. (Note: This authority does not include explicit ability to execute the SQL.) </li></ul></ul><ul><li>WLMADM authority </li></ul><ul><ul><li>Allows management of workload objects for the database. </li></ul></ul><ul><li>SQLADM authority </li></ul><ul><ul><li>Ability to manage event monitors </li></ul></ul><ul><ul><li>Ability to manage package and optimization caches </li></ul></ul><ul><ul><li>Also conveys EXPLAIN authority (see above) </li></ul></ul>
    • 10. <ul><li>DATAACCESS and ACCESSCTRL authorities will be granted to ids that currently hold DBADM. </li></ul><ul><li>DBADM, DATAACCESS, and ACCESSCTRL are granted to the SYSADM GROUP. </li></ul><ul><li>If migrating from a version of DB2 prior to 9.1, or a database that does not have a SECADM authority assigned, then, by default, the SECADM authority for the migrated database will be granted to the user id performing the migration . </li></ul>
    • 11. Limiting the DBAs <ul><li>Do you really want DBADMS to have it all? </li></ul><ul><li>Who holds DBADM? It’s a good idea to check. You might be surprised. </li></ul><ul><li>Determine what authority “must” be held by each specific DBA and assign only that and nothing more. </li></ul><ul><li>> > > Reducing authority does not imply mistrust < < < </li></ul><ul><li>Don’t “over” grant. It’s not wise and not necessary </li></ul><ul><li>Grant ACCESSCTRL and DATAACCESS authority separately </li></ul><ul><li>Only Grant DBADM ….. </li></ul><ul><li>without ACCESSCTRL and DATAACCESS </li></ul>
    • 12. Do DBAs Really Need It All? <ul><li>In the past, DBADM authority was granted to DBAs because there was no other appropriate High Level Authority. </li></ul>With DB2 9.7, the SECADM can Grant DBADM without also granting DATAACCESS or ACCESSCTRL
    • 13. Who is that DBADM Dude? <ul><li>#1) What are the AUTHIDs on the database and what are their AUTHIDTYPES? </li></ul><ul><li>SELECT char(AUTHID,35) as AUTHID, CASE AUTHIDTYPE when 'U' then 'USER' when 'G' then 'GROUP' when 'R' then 'ROLE' ELSE 'ERROR' END  as AUTHIDTYPE from SYSIBMADM.AUTHORIZATIONIDS </li></ul>
    • 14. <ul><li>#2) What authorizations have been granted to those ids? </li></ul><ul><li>For Example….To see what authorizations the USER, LOCKSMITH, has been granted, you could run: </li></ul><ul><li>SELECT AUTHORITY, D_USER, D_GROUP, D_PUBLIC, ROLE_USER, ROLE_GROUP, ROLE_PUBLIC, D_ROLE FROM TABLE (SYSPROC.AUTH_LIST_AUTHORITIES_FOR_AUTHID ('LOCKSMITH', 'U') ) AS T ORDER BY AUTHORITY </li></ul>
    • 15. <ul><li>#3) What ids have had DBADM granted to them via Direct Grants? </li></ul><ul><li>SELECT DISTINCT GRANTEE, GRANTEETYPE FROM SYSCAT.DBAUTH WHERE DBADMAUTH = 'Y' </li></ul>
    • 16. <ul><li>DBADMs can: </li></ul><ul><li>Create, alter, and drop non-security DB objects </li></ul><ul><li>Read log files </li></ul><ul><li>Work with event monitors (create, alter, drop) </li></ul><ul><li>Query tablespace states </li></ul><ul><li>Update log history files </li></ul><ul><li>Quiesce a tablespace </li></ul><ul><li>Reorganize tables </li></ul><ul><li>Runstats on catalog </li></ul><ul><li>SQLADM authority and WLMADM authority are subsets of the DBADM authority. (WLMADM authority has the ability to grant USAGE on workloads.) </li></ul>
    • 17. DB2 9.7 DBADM <ul><li>Cannot be granted to PUBLIC </li></ul><ul><li>Can only be granted or revoked by the SECADM </li></ul><ul><li>Can be granted to a user, a group, or a role. </li></ul>
    • 18. <ul><li>In DB2 9.7, the GRANT DBADM statement is more robust </li></ul><ul><li>$> db2 “grant DBADM on database to db2locksmith” statement still works, and it implicitly includes DATAACCESS and ACCESSCTRL authority. </li></ul><ul><li>But thinking about Least Privilege, I can instead use: </li></ul><ul><li>$> db2 &quot;grant dbadm without accessctrl without dataaccess on database to db2locksmith” </li></ul>Grant it Right Write Rite
    • 19. I want to take some authority back <ul><li>$> db2 revoke dbadm on database from locksmith </li></ul><ul><li>$> db2 &quot;SELECT char(AUTHORITY,35) AUTHORITY, D_USER </li></ul><ul><li>FROM TABLE (SYSPROC.AUTH_LIST_AUTHORITIES_FOR_AUTHID ('LOCKSMITH', 'U') ) AS T </li></ul><ul><li>where AUTHORITY in ('ACCESSCTRL','DATAACCESS','DBADM') ORDER BY AUTHORITY&quot; </li></ul><ul><li>AUTHORITY D_USER </li></ul><ul><li>----------------------------------- ------ </li></ul><ul><li>ACCESSCTRL Y </li></ul><ul><li>DATAACCESS Y </li></ul><ul><li>DBADM N </li></ul><ul><li>$> db2 &quot;REVOKE ACCESSCTRL, DATAACCESS ON DATABASE FROM locksmith&quot; </li></ul>
    • 20. My authority or yours? <ul><li>Some GREAT Aids for achieving Least Privilege: </li></ul><ul><li>SQLADM </li></ul><ul><ul><li>A Subset of DBADM </li></ul></ul><ul><ul><li>Lets others Monitor & Tune SQL Statements </li></ul></ul><ul><ul><li>This Authority includes EXPLAIN authority </li></ul></ul><ul><ul><li>Gives authority to do all tasks surrounding tuning, even runstats/reorgs </li></ul></ul>
    • 21. WLMADM <ul><li>Allows the holder to create, alter, drop, comment on, and grant and revoke access to workload manager objects. Also provides execute auth for the system defined Workload Management routines. </li></ul><ul><li>Can be granted by the SECADM or someone who holds ACCESSCTRL authority.  </li></ul><ul><li>Can be granted to a user, a group, a role, or to PUBLIC </li></ul><ul><li>( I would not suggest you grant to Public )  </li></ul>
    • 22. Explain it <ul><li>What you can say to Developers and Testers: </li></ul><ul><li>“ EXPLAIN yourself” </li></ul><ul><li>The EXPLAIN authority level provides administrative authority to explain query plans without gaining access to data. </li></ul><ul><li>EXPLAIN is also granted as part of the SQLADM authority </li></ul>
    • 23. Locksmith’s Corp The Locksmith Says:
    • 24. Starting with SYSADM <ul><li>Assigned via Group Membership </li></ul><ul><li>One of the DBAs (DBA1) will need to hold SYSADM. </li></ul><ul><li>db2 &quot;update dbm cfg using SYSADM_GROUP SGURU_Grp” (DBA1 is a member of that group). </li></ul><ul><li>Note: Windows -- LocalSystem account is considered a SYSADM if DBM sysadm_group is not specified. </li></ul>
    • 25. <ul><li>db2 &quot;select char(grantee,30) grantee from syscat.dbauth where securityadmauth = 'Y'&quot; </li></ul><ul><li>GRANTEE </li></ul><ul><li>------------------------------ </li></ul><ul><li>LOCKSMITH </li></ul>
    • 26. A BUSY SECADM <ul><li>DBA2 is a top DBA. She does not perform grants or revokes and does not need to query data. </li></ul><ul><li>She needs: </li></ul><ul><li>Create, alter, and drop non-security DB objects </li></ul><ul><li>Read log files </li></ul><ul><li>To work with event monitors (create, alter, drop) </li></ul><ul><li>Query tablespace states </li></ul><ul><li>Update log history files </li></ul><ul><li>Quiesce a tablespace </li></ul><ul><li>Reorganize tables & Runstats on Catalog </li></ul>
    • 27. DBA2’s Authority <ul><li>db2 connect to mydb user locksmith </li></ul><ul><li>db2 create role topdba </li></ul><ul><li>db2 grant dbadm without dataaccess without accessctrl on database to role topdba </li></ul><ul><li>db2 grant role topdba to DBA2 </li></ul>
    • 28. Busy DBAs <ul><li>To keep development going, some DBAs need to have the ability to grant/revoke. They also need to be able to do all SQL tuning tasks and peform reorgs/runstats. </li></ul><ul><li>db2 create role appdb </li></ul><ul><li>db2 grant accessctrl, sqladm on database to role appdb </li></ul>
    • 29. Busy Developers <ul><li>Developers probably should not be working in production, but even Dev and Test environments should have security controls. If nothing else, enforcing LEAST PRIVILEGE can save some unintended consequences…like updates to an incorrect table. </li></ul>
    • 30. Protect Developers & Yourself! <ul><li>db2 create role devusr </li></ul><ul><li>db2 create role devtbls </li></ul><ul><li>db2 create role devexpln </li></ul><ul><li>What now? </li></ul>
    • 31. <ul><li>db2 grant connect on database to role devusr </li></ul><ul><li>db2 grant select, insert on locksmith.employee to role devtbls </li></ul><ul><li>db2 grant select on locksmith.sales to role devtbls </li></ul><ul><li>db2 grant select on syscat.tables to role devtbls </li></ul><ul><li>db2 grant explain on database to role devexpln </li></ul><ul><li>db2 grant role devusr, devtbls, devexpln to Fred </li></ul><ul><li>db2 grant role devusr, devtbls to Rebecca </li></ul>
    • 32. Possibilities ? <ul><li>As you can see, you can get very granular with your approach separation of duties. </li></ul><ul><li>Using Roles, you could do things like: </li></ul><ul><li>Create Separate Roles for: </li></ul><ul><li>Explain </li></ul><ul><li>Accessctrl </li></ul><ul><li>Dataaccess </li></ul><ul><li>And then grant only what is needed </li></ul>
    • 33. Over Granting Time for the Breakup! <ul><li>There is so much granularity available, there is really no need to over grant. </li></ul><ul><li>And the ability to use Roles means that you have a Plug and Play Approach </li></ul><ul><li>Roles can be Granted to form a Role Hierarchy </li></ul><ul><li>Revoking is so much easier when you use Roles as well. </li></ul>
    • 34. The Benefit <ul><li>The ability to use these new features of DB2 9.7, especially when coupled with the use of Roles that were introduced in DB2 9.5, allows a better match between job responsibilities and database access. </li></ul><ul><li>The granularity is significant and allows fine grained control. </li></ul><ul><li>Use it to your advantage. </li></ul>
    • 35. Rebecca Bond, CISSP A.K.A. DB2Locksmith 434-DB2-0070 [email_address] A Locksmith’s Approach to Separation of Duties (SoD)

    ×