Wall of Text #14: Information security for dev

อยากเขียนเรื่อง security บ้าง หลังๆ ทำงานกับ security team เยอะขึ้น แล้วรู้สึกว่าจริงๆ มันไม่ยากอย่างที่คิด

Threat

ตอนที่เรียน information security ชอบรูปนี้มาก รู้สึกว่าอธิบายได้ดี เคยเจอรูปต้นฉบับในเน็ต แต่เข้าใจว่าหนังสือมีลิขสิทธิ์เลยหายาก ก็เลยวาดให้ใหม่ใน Paint

Security มีองค์ประกอบอยู่ 3 อย่าง

  1. Threat (ภัยอันตราย) ในรูปก็คือน้ำจะท่วมแล้ว
  2. Vulnerability (จุดอ่อน) ในรูปก็คือ กำแพงกันน้ำมีรอยรั่ว
  3. Control (การควบคุม) ในรูปก็คือเอามือปิดรอยรั่วไว้

ถ้ากำแพงรั่วแล้วเอามือปิดไว้ ผลคือน้ำไม่ท่วม เท่ากับว่าบรรลุเป้าหมาย แปลว่ามี security แต่ถ้าเกิดน้ำสูงกว่ากำแพงก็สร้างปัญหาได้อยู่ดี

CIA Triad

Security จริงๆ แล้วมีสมบัติ 3 อย่างหลักๆ ซึ่งอาจจะซอยข้อย่อยได้อีก 3 อย่างหลักๆ นี้คือ

  1. Confidentiality (ลับ) คือคนที่จะเห็นข้อมูลได้ต้องเป็นคนที่ตั้งใจจะให้เห็นเท่านั้น
  2. Integrity (สมบูรณ์) คือข้อมูลถูกต้องครบถ้วน เช่น ถ้ามี hacker เข้ามาเปลี่ยนหน้าเว็บเป็น rickroll ถือว่าเสีย Integrity
  3. Availability (ใช้งานได้) เช่น โดนยิง DDoS คนเข้าใช้งานไม่ได้เลย ถึงจะไม่ทำให้ข้อมูลหลุดหรือโดนแก้ไขข้อมูลก็เป็นปัญหา security เหมือนกัน

ซึ่งก็มีมาตรการต่างๆ ที่ช่วยรักษาสมบัติพวกนี้ เช่น

  1. Confidentiality
    • Access control ไม่ให้คนที่ไม่อนุญาตเข้าถึงได้ เช่นระบบ user account, firewall
    • Encryption เข้าถึงได้แต่เปิดอ่านไม่ได้
    • Contract เซ็นสัญญาไม่เปิดเผยความลับ ก็ใช้ควบคุมได้ถ้าไม่ได้อยู่ในระบบคอมพิวเตอร์
    • Monitoring ตรวจจับว่ามีผู้บุกรุก
  2. Integrity
    • Checksum คือสามารถยืนยันได้ว่าข้อมูลถูกต้องครบถ้วน
    • Signing คือจำกัดให้ checksum สร้างได้จำกัดคน ป้องกัน hacker สร้าง checksum ใหม่
    • Backup
    • Access control จำกัดคนที่แก้ไขข้อมูลได้ก็ช่วยได้เช่นกัน
    • Monitoring ก็ช่วยได้อีกเช่นกัน
  3. Availability
    • Spare มีระบบสำรองกรณีระบบหลักมีปัญหา
    • Scale out มีหลายๆ ระบบทำงานพร้อมกันเพื่อลดคอขวดจากจุดเดียว
    • Monitoring ว่าระบบยังทำงานได้ปกติ ไม่มีการใช้งานผิดปกติ

Security assessment

ไม่แน่ใจว่าตำรา security จะเขียนแตกต่างจากนี้ไหม แต่โดยทั่วๆ ไปแล้วเวลาผมประเมินความเสี่ยงจาก security จะทำตามขั้นตอนนี้ ซึ่งจริงๆ ผมว่ามันจะคล้ายๆ กับการทำ Persona ของ UX

  1. Threat modeling พูดง่ายๆ คือ กลัวอะไรอยู่ หลักๆ ก็อาจจะเป็น
    • กลัวคนนอก (hacker)
    • กลัวคนใน (insider attack, data loss)
    • กลัว user อื่น (spammer)
    • กลัวแอพพลิเคชั่นอื่น (lateral movement)
    • กลัวโปรแกรมเมอร์คนอื่น (defensive coding)
    • ซึ่งเราอาจจะไม่ต้องกลัวทุกอย่างก็ได้ เช่นเว็บเล็กๆ มีทีมงานเห็นๆ กันอยู่ 2-3 คน โอกาสที่คนในจะเป็นหนอนอาจจะน้อยก็ไม่จำเป็นต้องทำเรื่อง insider attack
  2. Vulnerability – ลอง list ออกมาว่าเขาจะทำอะไรมิดีมิร้ายได้บ้าง ผมคิดว่า list ทั้งหมดน่าจะยาวมากไม่สามารถเขียนมาได้ ต้องใช้ประสบการณ์ที่จะเห็นแล้วพอนึกออกว่ามีข้อไหนบ้างที่ apply เช่น
    • คนนอกอาจจะ port scan, เอาช่องโหว่มา scan, ทำ SQL injection หรือ XSS, เดารหัสผ่าน หรือ credential stuffing
    • คนในที่มี admin อาจจะใช้อำนาจในทางที่ผิด เช่น โกรธแฟนเลยแอบดูข้อมูลการใช้งานของแฟน (insider attack) โดนหลอกให้ทำ (phishing) หรือขโมยข้อมูลไปให้คู่แข่ง (data loss)
    • user อาจจะส่ง spam หากันเอง
    • คนใน หรือ application ใน network โดนฝัง shell แล้ว scan หา application ภายในเพื่อ hack ต่อ (lateral movement)
    • โปรแกรมเมอร์คนอื่นที่มาเรียกฟังค์ชั่นนี้อาจจะส่ง parameter มาผิดวิธีแล้วทำให้เกิดช่องโหว่ เช่นเรียก sql query แต่ไม่ได้ escape quote
  3. Control เป็นส่วนสำคัญที่สุด ถ้าเรามี control เพียงพอจะ run Ubuntu 8.04 ใน production ก็ได้ ตัวอย่างของ control เช่น
    • ทำ input validation ถ้าเป็นค่าที่ไม่ถูกต้องไม่ให้ประมวลผล
    • อัพเดต Application ให้ล่าสุดเพื่อไม่ให้โดน hack จาก library ที่ไม่อัพเดต เช่น Log4shell, Apache Struts
    • แต่บางที vendor อาจจะยังออก patch ไม่ทัน ก็ต้องกันจากด้านนอกเช่นใช้ WAF SaaS เพื่อตรวจจับการยิง
    • แต่ WAF ก็ bypass ได้ อาจจะเพิ่ม firewall ไปอีกเพื่อจำกัด IP ที่เข้าใช้งานได้กรณีที่เป็นระบบปิด
    • เพิ่ม firewall ขาออกด้านในด้วยเพื่อที่ว่ายิงเข้ามาได้ก็อาจจะส่งข้อมูลออกไป internet ยาก และเข้าไปโจมตี application อื่นๆ ยาก
    • สุดท้ายเพิ่ม access log เพื่อที่ว่าถ้ามีคนทะลุทุกอย่างมาได้จริงยังสามารถจับมือคนดมได้

“Control ที่เพียงพอ” เป็นคำถามที่ตอบยากมากๆ เพราะระบบที่ปลอดภัย 100% ไม่มีจริง ยิ่งทำมากยิ่งเสียเวลา (diminishing return) และทำให้ใช้งานลำบากด้วย อีกส่วนหนึ่งคือมูลค่าของระบบที่จะปกป้องกับระบบรักษาความปลอดภัยควรจะเหมาะสมกัน เช่นถ้าเป็นเว็บ company profile ธรรมดาๆ การซื้อ WAF, L7 firewall มาติดตั้งอาจจะมูลค่าหลักแสนหรือหลักล้าน แต่ความเสียหายคือแค่ restore จาก backup ก็กลับมาใช้งานได้แล้ว แบบนี้ก็ถือว่า backup เป็น control ที่เพียงพอแล้ว

เวลาเขียนโค้ด โค้ดทุกบรรทัดต้องทำ security assessment แบบนี้เสมอ ซึ่งคนส่วนมากน่าจะคิดว่าโอเวอร์เกินไปแล้วไม่ทำเลย แต่ผมคิดว่าถ้ามีประสบการณ์ security มาบ้างจะเริ่มจับทางได้เหมือนเป็น code smell ประเภทหนึ่งว่าในจุดนี้ต้องเริ่มวิเคราะห์ threat modeling อย่างละเอียดแล้ว ทำให้ทำงานได้เร็วขึ้น เช่น

  • ทุกจุดที่ใช้ตัวแปรที่ user ป้อนเข้ามา (โดนแฮคได้หลายแบบ ตามด้านล่างนี้)
  • โค้ดเกี่ยวกับ password (ตรวจดูว่า hash รหัสด้วยอัลกอริธึมและพารามิเตอร์ที่เหมาะสม และเปรียบเทียบรหัสผ่านโดยใช้เวลาคงที่ (constant time comparison))
  • โค้ดที่เกี่ยวกับวิทยาการรหัสลับ (ไม่แนะนำให้ใช้ algorithm โดยตรง ควรจะใช้ use case based library)
  • โค้ดที่ยิง URL แล้ว user กำหนดค่าเองได้ (อาจสุ่มเสี่ยง SSRF หรือ logic ในการ parse กับ validate ไม่ตรงกัน)
  • โค้ดที่รันสคริปต์ที่ user ส่งเข้ามา (ควรจะทำ sandbox ให้เหมาะสม)
  • โค้ดที่ใช้ตรวจสอบข้อมูล (data validation)
  • โค้ดที่จัดการข้อมูลขนาดใหญ่ในครั้งเดียว (ระวังไม่ให้ user ใช้งาน memory หรือ disk ใหญ่เกินไป)

Defense in Depth

ในอุตสาหกรรมการบินจะมีการใช้ Swiss cheese model

By BenAveling – Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=91881875

โมเดลนี้ใช้แนวคิดว่าเราไม่สามารถป้องกันความเสี่ยงได้ 100% ถ้าไม่อยากให้ชีสมีรูทะลุไปอีกฝั่ง การมีชีสเรียงกันหลายๆ ชั้นก็ลดโอกาสที่ชีสทุกแผ่นจะมีรูเดียวกันหมดได้ ในฝั่ง security มักจะเรียกว่า defense in depth

Not security

บางอย่างไม่ทำให้เกิด security

Security theater

เล่นละครไม่ทำให้เกิด security

เช่น นโยบายบอกว่าต้องตรวจสัมภาระก่อนเข้าสู่สถานที่ แต่คนตรวจเปิดอยู่ช่องเดียวแล้วส่องไฟผ่านๆ แบบนี้ไม่เกิดความปลอดภัย

Security is not a product

คนที่ไม่เข้าใจ security มักจะโดนเซลเป่าหูให้ซื้อ security product แต่ไม่ทำให้เกิด security จริง เปรียบเสมือนเช่ายันต์และห้อยพระเครื่องไว้ที่ server ให้อึด ถึก ทน ยิงไม่เข้า (ถ้า product มันเหนียวจริง ซื้อมาแล้วโดนแฮคควรจะฟ้องร้อง vendor ให้ใช้ค่าเสียหายได้)

การซื้อ product อาจจะช่วยเพิ่ม security ได้จริง แต่ก็ต้องกลับไปมองที่ security assessment ว่าสิ่งที่ซื้อมา ซื้อเพราะกลัวอะไร ซื้อแล้วมันได้ผลจริงกี่ % ซึ่งมันไม่ใช่ 100% แน่ๆ ต้องมีแผนให้ชัดเจนว่า control ต้องเพิ่มอะไรอีกบ้างจึงจะเพียงพอ

Security is not a feature

Project manager ที่ไม่เข้าใจ security อาจคิดว่า security เป็น feature หนึ่งแล้วก็แยกเป็น ticket low priority ทำทีหลัง

ผ่านไป 1 ปีก็ยังไม่ได้ทำจนกระทั่งโดน hack แล้วบอกว่าลูกค้าด่าต้องทำให้เสร็จภายใน 1 สัปดาห์

ในความเป็นจริงแล้ว security เป็นส่วนหนึ่งของทุกๆ feature การ “เติม” security เข้าไปภายหลังสร้าง technical debt ได้รวดเร็วมากเพราะมันมักจะส่งผลต่อ design และการแก้ design flaw เป็นเรื่องยาก ใช้เวลานาน

Security by obscurity

Security ที่แท้จริงถ้าเฉลยกลให้ทั้งหมดแต่ไม่บอกรหัสลับก็ไม่สามารถผ่านเข้ามาได้ เช่นวิธีเข้ารหัส AES นั้นเป็นข้อมูลเปิดเผยหาอ่านได้ทั่วไป ถึงอย่างนั้นถ้าไม่บอกกุญแจเข้ารหัสปัจจุบันยังไม่มีใครถอดรหัสข้อความใดๆ ได้

โบราณว่า ทองแท้ไม่แพ้ไฟ

มีบางคนคิดว่า AES เป็นข้อมูลเปิดเผย มี paper มากมายที่ลดความปลอดภัยของ AES ถ้าอย่างนั้นเราออกแบบ algorithm ขึ้นมาเองเฉพาะภายในบริษัทแล้วก็เป็น algorithm ที่มีความปลอดภัยสูงสุด ไม่เคยมีผู้ใดในโลกถอดรหัสได้โดยไม่ต้องรู้กุญแจ

ผ่านไป 6 เดือน hacker reverse engineer โปรแกรมมาดูแล้วพบว่าเป็น XOR กับ hardcode key ธรรมดาๆ แล้วก็เอา key ไปแจกในเน็ต

People is the weakest link

xkcd 538

Cargo cult security

“อาจารย์บอกมา” ไม่ใช่ security ที่ดีเสมอไป เช่น

  • อาจารย์ให้ config มา ตั้งตามแบบนี้แล้วเหนียว ยิงไม่เข้า แต่พอใช้แล้ว CEO โดนบล็อกทำงานไม่ได้
  • อาจารย์สอนให้ต้องมี CSP header แล้วจะป้องกันการแฮคได้ แต่เปิด unsafe-eval ไว้เพราะ marketing จะใช้ Google Tag Manager
  • อาจารย์สอนวิธี encrypt รหัสผ่านด้วย MD5 แล้วทำให้รหัสผ่านปลอดภัย แฮคไม่ได้
  • ซื้อ Tool scan มา scan เจอ 500 ข้อ พอแก้ตามที่ tool แนะนำแล้ว application ใช้งานไม่ได้
  • ซื้อ Tool scan มา scan ก่อน release application ปรากฏว่าจะแก้ให้ผ่านเป็น breaking change ส่งมอบงานไม่ทันเวลา
  • ซื้อ Tool scan ช่องโหว่ 10 อันดับยอดนิยมมา scan แล้วไม่เจอสักรายการที่ต้องแก้ไขแสดงว่าปลอดภัย แต่โดน hack ด้วยช่องโหว่ยอดนิยมอันดับที่ 11

เขาว่ายอด consult จะบอกว่า It depends ซึ่ง security ก็เช่นกัน “อาจารย์บอกมา” อาจจะไม่ได้ผิด แต่ไม่สามารถคำนึงถึง It depends ได้ ต้องมีความเข้าใจที่ถูกต้องว่าทำไมอาจารย์ถึงบอกมา

Language Maturity by Library

ช่วงนึงเคยนั่งดูภาษาใหม่ๆ เผื่อจะเลือกมาเขียน

อย่างนึงที่พบคือภาษาเองไม่ได้สำคัญเท่ากับ library ที่ภาษานั้นมี เช่น คนเขียน Ruby กลุ่มใหญ่ๆ ก็ไปเพราะ Ruby on Rails, ถ้าจะเขียน data science ถ้าไม่ใช้ Python แล้วก็ทำงานลำบากมาก

ตอนที่หัด Rust แรกๆ นานมาแล้ว ตอนนั้นก็พบว่า library ของภาษาค่อนข้างมี maturity ต่ำมาก คือบางอันก็มีแต่ใช้งานไม่ได้ บางอันก็ไม่มี เลยคิดว่าทำ checklist ขึ้นมาว่าภาษาควรจะมี library อะไรบ้างถึงจะใช้งานทั่วไปได้บ้าง เวลา evaluate ภาษาจะได้ดูได้ง่ายขึ้นว่ามันพร้อมใช้งานแล้วหรือยัง

Language fundamentals

คิดว่าภาษาสมัยใหม่น่าจะมีพวกนี้อยู่แล้ว อาจจะเป็น first class เลยด้วยซ้ำคือรองรับในภาษาเลย ถ้าเป็นภาษาเก่าแบบ C อาจจะไม่มี

  • Unicode string และ function ที่จัดการกับตัวอักษร เช่น to uppercase, lowercase
  • Byte array (uint8 array) ในบางภาษามีแต่ string ก็มี ไม่สามารถเก็บ raw bytes ได้
  • Data structure ต่างๆ ที่สำคัญคือ ArrayList (Array ที่ไม่ระบุจำนวนสมาชิกล่วงหน้า) และ Map (Key-value store)
  • Threading ซึ่งถ้าเป็นภาษาเฉพาะทางหน่อยอาจจะไม่มี เช่น PHP หรือ JavaScript จะไม่อยู่ในแกนของภาษา
    • Synchronization primitives เช่น Mutex, RWLock, Barrier, Atomic operations
  • Timers ต่างๆ เช่น get time, sleep, monotonic clock (นาฬิกาที่เดินไปข้างหน้าอย่างเดียวถึงแม้ user จะปรับเวลาเครื่อง)
  • Date/Time calculation (with timezone) ซึ่งความยากคือ timezone เป็นข้อมูลที่ dynamic ประเทศต่างๆ อาจจะปรับเวลา daylight saving เมื่อไรก็ได้ บางภาษาเช่น Java ก็รวมฐานข้อมูลเข้ามาใน runtime บางภาษาเช่น Python ก็มีการเก็บ timezone แต่ไม่มีข้อมูลโลกจริงต้องไปใช้ library ภายนอก (pytz)
  • String templating พื้นฐาน ก็คือแบบ sprintf
  • Regular Expression
  • Pseudorandom และ Secure random
  • Path mutation function เช่น basename, dirname, join path
  • OS signal handler (ทำอย่างไรเมื่อโดน SIGINT?)

อีกส่วนที่จะช่วยได้เยอะ คือภาษาสามารถโหลด dynamic library ภาษา C เข้ามาได้และเรียกฟังค์ชั่นจากภาษา C ได้ซึ่งจะทำให้การต่อยอดขั้นถัดไปได้เยอะ

Interop

โปรแกรมที่ยากกว่า Programming มัธยมมักจะเริ่มต้องเชื่อมต่อกับระบบอื่นๆ บ้าง ซึ่งที่คิดว่าจำเป็นจะต้องมีคือ

  • Base64
  • JSON serializer/deserializer ซึ่งถ้าให้ดีควรจะใช้งานกับ data structure ใดๆ ของภาษาก็ได้ (POJO)
  • TCP/UDP socket
  • TLS socket ซึ่งง่ายที่สุดก็คือใช้ C FFI คุยกับ OpenSSL แต่บางภาษาก็อาจจะ implement ใน runtime แล้วไม่มี API ให้
  • Data encryption, hashing ซึ่งส่วนมากที่เห็นก็จะใช้ OpenSSL ทำเหมือนกัน
  • Byte stream encoder/decoder
  • Gzip
  • HTTP ซึ่งต้องใช้ฟีเจอร์หลายๆ ข้อด้านบน

Advanced language fundamentals

  • Unit testing library
    • Report เป็นแบบ Junit XML (ซึ่งก็น่าจะต้องมี XML encoder)
  • Documentation generator บางภาษาอาจจะไม่มีที่เขียนในภาษาตัวเอง แต่ไปแก้ tool ภาษาอื่นเช่น Sphinx, Doxygen ให้เข้าใจไฟล์ของมันได้แทน
  • Command line argument parser ผมค่อนข้าง prefer แบบ UNIX แต่บางภาษา (เช่น Go) ก็ทำแบบของตัวเองก็มี
  • Async IO บางภาษาก็ built in ไปเลย เช่น Go หรือหลายๆ ภาษาก็มี await keyword แล้วแต่ยังต้องแยก function ระหว่างประเภทที่เป็น sync กับ async ซึ่งผมคิดว่าไม่ดีเท่าไร (What color is your function?) จุดที่น่าสังเกตในภาษานั้นๆ คือใครจัดการ event loop เช่นใน Go, JavaScript นั้น runtime จัดการให้ ส่วนใน Python ถึงจะมี async แต่เราต้อง start event loop เองทำให้ทำงานลำบาก เรียกว่ามีเป็น library ยังไงก็ไม่ดีเท่า support ภายในภาษาเอง
  • Templating ขั้นสูง
    • Handlebars คิดว่าเป็นมาตรฐานต่ำสุด คือมี if, loop เท่านั้น
    • ขั้นสูงไปกว่านั้นควรจะมี variable filters (หรือ arbitrary function call), auto HTML escape, template inheritance ซึ่งถ้ามีหมดนี่ เท่าที่เห็นมักจะเป็นสไตล์ Django/Jinja (Smarty/Twig, Twigy, Pongo2)
  • Data validation ซึ่งจริงๆ เขียนเป็น if/else ก็ได้ แต่จะทำให้โค้ดรกและซ้ำซ้อน
  • Big number หรือจำนวนที่ใหญ่กว่าขนาด max int ปกติ
  • Decimal คือจำนวนทศนิยมที่แม่นยำ มักใช้ในการเงิน
  • Logging ซึ่งควรจะมีฟีเจอร์ดังนี้
    • Leveled logging คือกำหนดระดับของ log ได้ เช่น trace, debug, info, warning, error, fatal และปิดระดับที่ไม่ต้องการได้
    • Logging facility คือ config log level/output แยกตาม module ได้
    • JSON format / Human format ท่าที่น่าสนใจคือ library บางตัวเช่น bunyan ออกเป็น JSON เสมอ แล้วค่อย pipe ใส่ tool ให้จัดรูปใหม่บน client side แทน
    • Structured logging คือระบุ key-value ประกอบ log ได้โดยไม่ต้องนั่งเขียน message
  • Curses หรือ terminal GUI

Advanced interop

Standard ใหม่ๆ ที่ใช้หลายอันเริ่มมีความซับซ้อนสูงจนหลายๆ ภาษาอาจจะมีไม่ครบ ซึ่งที่คิดว่าควรจะมีคือ

  • YAML ซึ่งเป็น superset ของ JSON มี edge case มากมาย แต่ก็นิยมใช้เป็น config file จึงควรจะต้องรองรับไว้
  • Protobuf 3 ข้อนี้ผมคิดว่าค่อนข้าง opinionated เพราะ Thrift ก็มีคนใช้พอสมควรเหมือนกัน แต่คิดว่าควรจะมี binary encoding สักรูปแบบที่ portable ข้ามภาษาได้
  • HTTP/2 ผมยังไม่ค่อยเห็นคน implement API HTTP/2 ออกมาตรงๆ จะเป็นลักษณะว่าทำให้ HTTP client ใช้ HTTP/2 ได้แบบ transparent มากกว่า
  • SQL Database Access ซึ่งหลายๆ ภาษามักจะมี API กลาง (PDO, JDBC, database/sql) และ database driver แยกส่วนกันชัดเจน

Use case specific

ในขั้น use case ที่ใช้งานได้จริง ภาษาควรจะมี library พวกนี้ตามแต่ use case

  • gRPC client ถ้ามี 2 ข้อด้านบนแล้วจึงจะสามารถ implement ได้ เช่นเดียวกันผมคิดว่าข้อนี้ค่อนข้าง opinionated มากๆ มันเป็น standard ที่ซับซ้อนมากๆ และยังพอจะ design หลบไปใช้ HTTP ได้อยู่
  • gRPC server คิดว่าควรจะแยกข้อกันกับ client ด้วย ผมคิดว่า server สำคัญกว่า client แต่มักจะ implement ยากกว่า ท่าที่ gRPC เคยทำในหลายๆ ภาษา (Python, JavaScript) คือเรียกไปที่ C FFI เลย
  • Desktop GUI library ซึ่งแม้แต่ใน Go ผมก็ยังเห็นว่ามันยังไม่ค่อย mature เท่าไร
  • Graphics drawing library
  • Image processing เช่น เปิดไฟล์ภาพ ย่อขยาย ปรับสี, สว่าง มืด, blur
  • Generate QR code อาจจะเป็น terminal หรือ image
  • WebSocket client/server
  • Monitoring support เช่น Remote exception catcher, tracing, metrics
  • Unix function ต่างๆ เช่น syslog, shared memory